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ABSTRACT 


The purpose of this researeh was to introduee a Transformational 
Communications Architecture for the Unit Operations Center (UOC); Common Aviation 
Command and Control System (CAC2S); and Command and Control On-the-Move 
Network, Digital Over-the-Horizon Relay (CoNDOR). 

The methodology used was to conduct Field Tests with government contractors 
and private vendors in order to demonstrate the capabilities of each wireless technology 
researched. These wireless technologies, Free Space Optics (FSO), Microwave, 802.16, 
802.11b over SecNet-11, Orthogonal Frequency Division Multiplexing (OFDM), 
Broadband Satellite, INMARSAT, and Iridium, all have the potential of being 
implemented in the transformational communications architecture for intra-nodal and 
inter-nodal links for UOC and CAC2S, as well as the CoNDOR communications 
architecture. The ultimate goal of this research was to introduce different technologies 
that offer more flexibility, mobility, and capability at the tactical level giving the Marine 
Corps the tactical wireless edge. 

Throughout this research, the focus revolved around testing equipment and 
network configurations in an IP network. Special consideration was given to wireless 
issues for the UOC, CAC2S, and CoNDOR, which could improve line-of-sight, beyond 
line-of-sight, and over-the-horizon communications for each program. These new 
technologies will transform communications in the United States Marine Corps for the 
2U* century. 


V 



THIS PAGE INTENTIONALLY LEET BLANK 


VI 



THESIS ROADMAP 


For readers who need a quiek explanation of this thesis research, read the 
executive summary, conclusions, and recommendations. The reader will find the thesis 
in the following order: table of contents, list of figures, list of tables, acknowledgements, 
executive summary. Chapter I (Introduction), Chapter II (Field Tests), Chapter III 
(Findings and Analysis), Chapter IV (Conclusions), Chapter V (Recommendations), 
Appendix, list of acronyms, and initial distribution list. 

Chapter I discusses the problem and background information on UOC, CAC2S, 
and CoNDOR. The problem addresses the fundamental reason for conducting this thesis 
research, and the background information gives a summary of the different programs that 
are being studied. 

Chapter II explains in detail how each field test was conducted. This chapter only 
discusses the procedures of each field test. For results of each test, the reader must read 
Chapter III (Findings and Analysis). Chapter III summarizes the results of the four field 
tests and gives detailed findings and analysis. 

Chapter IV discusses the conclusions for the UOC, CAC2S, and CoNDOR 
programs. In this chapter, the technologies examined are associated with the potential 
use in each program. 

Chapter V provides recommendations for the UOC, CAC2S, and CoNDOR 
programs. The reader can learn what can be implemented now in each program. In 
addition, the reader can find out what could be implemented in the future for each 
program, how this research ties into a FORCEnet application, and what can be done as 
follow-on research. 

The Appendix contains a summary of each product used in this thesis research 
and supplemental information that further assists the reader while reading the paper. 

Finally, the thesis ends with a list of acronyms and an initial distribution list. 
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EXECUTIVE SUMMARY 


The purpose of this researeh was to introduee a Transformational 
Communications Architecture for the Unit Operations Center (UOC); Common Aviation 
Command and Control System (CAC2S); and Command and Control On-the-Move 
Network, Digital Over-the-Horizon Relay (CoNDOR). 

Through funding from Marine Corps Systems Command (MCSC) and several 
Naval Postgraduate School (NPS) professors, Captain Joseforsky and Captain Garcia set 
out in October 2003 to conduct face-to-face interviews with their sponsors and several 
commercial vendors that could potentially help them with their thesis work. After this 
trip, they formulated a plan to do ‘backyard’ testing of several commercial off-the-shelf 
technologies in the Monterey, CA area. Two months later after some intensive 
coordination, they went to General Dynamics in Scottsdale, AZ and Raytheon in San 
Diego, CA to conduct testing with the UOC and CAC2S program offices respectively. 
Finally, they completed their testing evolutions with a realistic tactical scenario that 
resembled the CoNDOR architecture at Camp Roberts, CA in March 2004. 

In November 2003, Captain Joseforsky and Captain Garcia orchestrated a team 
(LT Jesus “Manny” Cordero and LT A1 Seeman) in order to achieve individual thesis 
work for NPS. Overall, over 25 U.S. Government agencies, government contractors, and 
commercial vendors were coordinated in order to accomplish the various testing 
evolutions. Each of these events required detailed planning and execution in order for the 
companies to come in and demonstrate their technologies. The students managed to 
synchronize equipment to be temporarily utilized from all these companies in order to 
accomplish their thesis objectives. 

The wireless technologies that were researched. Free Space Optics (FSO), 
Microwave, 802.16, 802.11b over SecNet-11, Orthogonal Frequency Division 
Multiplexing (OFDM), Broadband Satellite, INMARSAT, and Iridium, all have the 
potential of being implemented in the transformational communications architecture for 
intra-nodal and inter-nodal links for UOC and CAC2S, as well as the CoNDOR 
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communications architecture. The table below gives the Pros and Cons of eaeh 
teehnology (Table 1). This table was the foundation for the reeommendation matrix seen 


below. 



FSO 

LOS 

Fiber throughput speeds, quick setup time, 
operates in license free spectrum 

Susceptible to weather conditions, 
short distance (< 5 km), laser alignment 

MICROWAVE (RFM) 

LOS 

Up to OC-3 speeds, already packaged, 
reaches out to 13 kilometers 

Obtain authorization for frequency use, 
susceptible to interception due to RF use 

802.16 

LOS 

Adaptive modulation, up to 66 Mbps, 

360 degree coverage out to 20 km 

No built-in encryption, company evaluated was 
ATM based (there are others IP based) 

802.11 b over SecNet-11 

LOS 

Type 1 encryption built-in, 
send up to secret level data, small footprint 

Low throughput of 1-2 Mbps, difficult to configure, 
not compatible with other 802.11 b 

OFDM 

BLOS 

Communicates over hills, through trees, and 
around buildings, 25 Mbps throughput 

Limited encryption built in, 
need good azimuth for BLOS connectivity 

BROADBAND SATELLITE 
(Segovia/Omega Systems) 

BLOS/OTH 

Large throughput capabilities of up to 9 Mbps, 
mountable on a vehicle. Type 1 encryption 

Annual/Monthly Fees, but not by minute 

INMARSAT 

(Nera) 

BLOS/OTH 

Satellite connectivity on-the-move, 
small mountable vehicle platform, encryption 

Expensive per minute fees, 
low throughput of 56 Kbps (working on upgrades) 

IRIDIUM 

BLOS/OTH 

Capable of combining four channels, 
comms on-the-move, no monthly fees 

Low throughput of 2.4 Kbps per channei, 
difficuit to send data without compression 


Table 1. TECHNOLOGY SUMMARY 


The ultimate goal of this researeh was to introduee different teehnologies that 
offer more flexibility, mobility, and eapability at the taetieal level giving the Marine 
Corps the taetieal wireless edge. During the Field Tests eondueted for this researeh 
project, the strengths and adaptability of the various produets were assessed. The 
reeommendations on how to best implement these teehnologies for UOC, CAC2S, and 
CoNDOR are given in the table below (Table 2). 
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Table 2. RECOMMENDATION OF WIRELESS TECHNOLOGIES 


The authors decided to combine the UOC and CAC2S recommendations together 
since the command and control systems have similar distance requirements when 
physically deployed on the battlefield and the requirements for communications on-the- 
move are very much alike. CoNDOR’s recommendations were kept separate since it is 
not a command and control system but rather a concept of connecting multiple echelons 
of command together. For UOC and CAC2S, there are four functional areas that 
communications requirements can fall under; intra-nodal, inter-nodal, communications 
on-the-move, and aerial relay. The CoNDOR concept revolves around the Point of 
Presence Vehicle (POP-V) so the functional areas were outlined as follows: into POP-V, 
out of POP-V, communications on-the-move, and aerial relay. 













































UOC/CAC2S 

By utilizing wireless teehnologies to link a Command Center to Antenna Hill 
within a UOC node or from Proeessing and Display Subsystem (PDS) to 
Communieations Subsystem (CS) and Sensor Data Subsystem (SDS) in a CAC2S node, 
the Marine Corps eould potentially replaee fiber eables that run between the sites. The 
intra-nodal setup is divided into two different eategories for eommunieations, LOS and 
BLOS. The LOS teehnologies researehed for the intra-nodal setup in the order of 
reeommendation are as follows: Free Spaee Opties (FSO), Mierowave, Orthogonal 
Frequeney Division Multiplexing (OFDM), 802.16, and 802.1 lb over SeeNet-11. FSO is 
the right fit for this short distanee of less than 2 kilometers due to its eapabilities shown 
in Table 1 above. OFDM was researehed and evaluated over the period of this thesis 
work. It has tremendous eapabilities of being plaeed in valleys near Antenna Hill where 
it ean be eamoufiaged without inhibiting the eapaeity of the link. The authors saw 
throughput up to 25 Mbps when in non-line-of-sight situations. 

Sinee the distanees between UOC and CAC2S nodes are unpredietable due to the 
frequent movement of units on the battlefield, line-of-sight (LOS), beyond line-of-sight 
(BLOS), and over-the-horizon (OTH), eould all be eneountered at any given time. In 
order of ranking, the following teehnologies are reeommended for use in LOS situations 
for the inter-nodal seenario: OFDM, 802.16, Mierowave, FSO, and 802.11b over 
SeeNet-11. OFDM is best suited for this type of setup sinee it is the most forgiving of 
the teehnologies if ideal LOS is not attained. While all of the LOS teehnologies beeome 
more and more ineapable of reaehing BLOS distanees, OFDM ean operate in LOS or 
BLOS situations. This makes the teehnology the number one reeommendation for inter- 
nodal BLOS seenarios. OFDM will maintain eonneetivity over hills, through trees, and 
around buildings. These are the rankings for OTH eommunieations in the inter-nodal 
seenario: Broadband satellite, INMARSAT, and Iridium. Broadband satellite provided 
by Segovia/Omega Systems ean replaee the TRC-170 setup for CAC2S with its 
eapabilities to reaeh up to 9 Mbps, and it is eomparable in size with the SMART-T 
system, but eould provide more throughput eapability for the UOC node. 
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OFDM is the first recommendation for communications on-the-move within a 
convoy because LOS does not need to be maintained while the vehicles are moving. 
Each vehicle can remain a safe distance away from the others, which ensures a good 
security posture. While the distance and terrain can vary greatly when communicating 
from a UOC/CAC2S forward echelon convoy back to the main, some type of satellite 
connectivity that can function on-the-move will be needed. INMARSAT is 
recommended ahead of Iridium due to its throughput capabilities. 

The use of aerial relays for UOC and CAC2S nodes can greatly increase inter- 
nodal communications. This could be an alternative to the MRC-142 or TRC-170, as the 
802.1 lb over SecNet-11 could be retransmitted via the airborne platform for hundreds of 
miles if the signal was amplified and appropriate antennas were utilized. If it is 
determined that OFDM can be amplified, then distance could equal that of 802.11b and 
greater flexibility is attained on where antennas would need to be placed on the ground to 
maintain connectivity with the airborne platform. 

CoNDOR 

The current plan for the CoNDOR scenario is to place a Point of Presence Vehicle 
(POP-V) at the battalion level to further enhance the capabilities of the subordinate units 
with low throughput capabilities. This vehicle will allow those units with EPLRS, 
SINCGARS, HE, HE Automatic Eink Establishment (ALE), and UHF SATCOM to have 
access to Major Subordinate Commands (MSCs) through the satellite connectivity at the 
battalion level. 

The EOS recommendations for the communications into the POP-V resemble the 
EOS rankings used for UOC and CAC2S. Since EPERS is currently the best form of 
data connectivity down to the lower levels at 56 Kbps, it is obvious that the technologies 
recommended would bring a new kind of capability down to the lowest level. The 
following technologies are recommended for EOS into the POP-V in the order of 
preference: FSO, Microwave, OFDM, 802.16, and 802.11b over SecNet-ll. For BLOS 
situations when communicating from the lower echelons to the POP-V, the following 
technologies are recommended in order of preference: OFDM, Broadband Satellite, 



INMARSAT, and Iridium. OFDM can become the teehnology of the future for the 
Marine Corps if it ean be properly enerypted in a eost effeetive manner. 

When eommunieating from the POP-V to an MSC, the seenario will most likely 
require some form of BLOS or OTH eonneetivity. In a BLOS situation, the following 
teehnologies are reeommended in the order of the authors preferenee: OFDM, 
Broadband satellite, INMARSAT, and Iridium. OFDM ean provide a terrestrial 
eonneetion up to 20 kilometers. The three teehnologies ranked for OTH eapability are 
Broadband satellite, INMARSAT, and Iridium. Segovia/Omega Systems Broadband 
satellite eonneetivity during Field Test Four was most impressive. They are able to vary 
the amount of throughput that is needed and ean provide private network eapabilities, 
Internet serviees, and phone serviees. Their link ean also be Type 1 enerypted, whieh 
eould provide SIPRNET eonneetivity. 

Communieations on-the-move is what the CoNDOR arehiteeture is built around. 
The following are the reeommendations in order of priority for eommunieations within 
the eonvoy: OFDM, 802.11b over SeeNet-11, and Iridium. OFDM will again provide 
suffieient bandwidth for a platoon/eompany-sized unit, enable a small footprint, and 
allow vehieles flexibility on where to loeate in a eonvoy. If there is a eompany or platoon 
size unit that is traveling in a eonvoy, then they need to have some means of maintaining 
eonneetivity to the POP-V in order to be eonneeted with all other units assoeiated with 
that POP-V. INMARSAT is the first reeommendation due to its strength of the on-board 
satellite terminal being able to traek the airborne satellite while in motion. 

The use of aerial relays for CoNDOR ean greatly inerease the ability to 
oommunieate from units to the POP-V and from the POP-V to MSCs. This eould be an 
alternative to relying on LOS radios or satellite eommunieations. Two teehnologies 
examined in this thesis are reeommended for use in the aerial relay platform, and they are 
802.1 lb over SeeNet-11 and OFDM. 

Bulk eneryption was utilized at General Dynamies and Raytheon. The KG-235 
In-Line Network Lneryptor proved eompatible with LSO, Mierowave, and OFDM, and it 
eould definitely work with the other teehnologies. Detailed analysis needs to be done on 
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how to configure the eneryptor appropriately for maximized throughput and where to 
plaee the KG-235 into the loeal area network. 

In eonelusion, the authors introdueed different teehnologies that offered more 
flexibility, mobility, and eapability for eommunieations on the taetieal battlefield. 
Throughout this researeh, the foeus revolved around testing equipment and network 
eonfigurations in an IP network in order to demonstrate a taetieal wireless edge. Speeial 
eonsideration was given to wireless issues for the UOC, CAC2S, and CoNDOR 
programs, whieh eould improve line-of-sight, beyond line-of-sight, and over-the-horizon 
oommunieations for eaeh of them. These new teehnologies will transform 
oommunieations in the United States Marine Corps for the 2U* eentury. 
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I. INTRODUCTION 


A. DISCUSSION OF THE PROBLEM 

The purpose of this research was to introduce a Transformational 
Communications Architecture for the U.S. Marine Corps’ Unit Operations Center (UOC); 
Common Aviation Command and Control System (CAC2S); and Command and Control 
On-the-Move Network, Digital Over-the-Horizon Relay (CoNDOR). 

The following three questions address the main issues being examined in this 

thesis: 

1. Can transformational communications technologies alter the intra- 
nodal communication links in UOC and CAC2S into a more capable and robust 
signal? 

2. Can transformational communications technologies provide more 
effective inter-nodal communications links between UOC and CAC2S nodes than 
current legacy equipment? 

3. Can transformational communications technologies be utilized in the 
CoNDOR scenario? 

The ultimate goal of this research will be to introduce different technologies that 
offer more flexibility, mobility, and capability at the tactical level than what current 
legacy equipment provides. These new technologies could provide the Marine Corps 
with a tactical wireless edge. 

A statement made by Major General Stalder, United States Marine Corps, Deputy 
Commanding General for I Marine Expeditionary Force (MEF) before the House Armed 
Services Committee on October 21, 2003 states the following about Operation Iraqi 
Freedom (OIF): 

In order to support the C2 systems, the MEF and its major subordinate 
commands incorporated several recently fielded communication 
technologies. Among these were the Secure Mobile Anti-Jam Reliable 
Tactical-Terminal (SMART-T), the Tactical Data Network (TDN) 
gateway, the Digital Technical Control (DTC) facility, and the Deployable 
KU Earth Terminal (DKET). Overall, these new technologies were a 
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great success story and contributed significantly to the MEF and Major 

Subordinate Command (MSC) Commanders’ ability to command and 

control forces in combat. i 

There have been numerous advances in satellite communications for the MSCs, 
but this thesis research will dig deeper into the tactical problem within the MSCs. 
Several units and agencies on the battlefield are still without similar types of 
communication means and lack the technology to effectively communicate in the new 
information age. 

1, Marine Corps Technology Problem 

The Marine Corps is developing new command and control systems such as UOC 
and CAC2S, and new concepts for Marine Expeditionary Forces to bridge the gap 
between Major Subordinate Commands (MSC) and their subordinate units, such as 
CoNDOR. If the Marine Corps continues to rely on legacy communications for these 
programs, the technology gap will widen even further than what already exists. New 
technologies, such as the ones researched in this thesis, need to be seriously considered to 
keep the warfighter one step ahead of the enemy. The authors will look at UOC, CAC2S, 
and CoNDOR and how to improve line-of-sight (EOS), beyond line-of-sight (BEOS), 
and over-the-horizon (OTH) communications in intra-nodal and inter-nodal 
environments. 

For a command and control system setup in the Marine Aviation Command and 
Control System (MACCS), the Marine Corps currently uses fiber optic cable to connect 
different sites in the intra-nodal scenario. For example, from Combat Operation Center 
(COC) to communications site, a heavy-duty fiber optic cable is run from one vehicle to 
another. If the wire is not buried, it becomes vulnerable to elements such as vehicles 
running over it or the enemy slashing the wire to sabotage the communications 
capabilities. This creates a significant single point of failure if multiple cables are not run 
between the sites. For the Ground Combat Element (GCE), large amounts of cable (fiber 
and/or multi-pair) and/or single pair field wire are currently used to remotely connect the 

1 Major General Stalder, USMC, Brief to House Armed Services Committee, Subcommittee on 
Terrorism, Unconventional Threats and Capabilities, 21 October 2003. 
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radios and other communications assets from COC to antenna hill. Thus, the same 
vulnerabilities exist for the GCE as the MACCS agencies. 

Next, for inter-nodal data communications the MACCS relies upon the A/N 
MRC-142 and the A/N TRC-170, while the ground units rely heavily on the MRC-142. 
The characteristics of the MRC-142 (Table 3) and the TRC-170 (Table 4) can be found 
below. 


Frequency range 

1.350- 1.850 MHz 

Bandwidth 

100 (125 optional) kHz 

Channel rate 

144. 288, and 576 kbps 

Output power 

Low: 300mW (25dBm) 

High: 3 W (35 dbni) 

Frequency Stability 

10 ppm 

Orderwire channel 

Analog: 300- 3.400 Hz 

Digital: 16 kbps 


Table 3. AN/MRC-142 CHARACTERISTICS2 


The AN/MRC-142 is also generally employed at or above the regimental level. It 
serves as a flexible, reliable voice and data link in the USMC digital switched backbone 
system. The AN/MRC-142 has a range of 35 miles, operates at data rates up to 576 Kbps, 
and will support a maximum of 36 voice channels. The AN/MRC-142’s enhanced 
bandwidth management and data throughput capabilities will enable other critical 
systems such as the Tactical Data Network (TDN) and the Advanced Eield Artillery 
Tactical Data System (AFATDS) to be fully integrated into Marine Air-Ground Task 
Force (MAGTF) operations ashore.3 


Frequency Range 

4 4- 5.0 GHz 

Bandwidth 

3.5 or 7.0 MHz 

Transmitter power 

1 kW 

Diversity 

Dual 

Data Rates 

Up to 4.608 kbps 

Channel capacity 
(at 32kbps) 

Up to 144 (includes overhead) 


Tabled. A/N TRC-170 CHARACTERISTICS4 

2 http://www.fas.org/man/dod-lQl/usmc/docs/mef99/part-2.pdf (April 2004). 

3 http://www.marcorsvscom.usmc.mil/sites/pmcomm/mrcl42.asp (April 2004) 

4 http://www.fas.org/man/dod-lQl/usmc/docs/mef99/part-2.pdf (April 2004). 
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The AN/TRC-170 is a transportable, self-enelosed multi-ehannel tropo-scatter 
terminal eapable of transmitting and receiving digital data over varying distances (up to 
100 miles). The MAGTF headquarters and Aviation Combat Element (ACE) will 
normally use it.5 

Erom the tables, the data rates shown are relatively low for the MRC-142 and 
somewhat sufficient for the TRC-170 compared to what will be needed in the future. 
These two systems are fairly large and require their own generators for power. The 
technologies examined in this thesis will definitely complement or provide more refined 
options than the MRC-142 and TRC-170. 

In the CoNDOR setup, the Marine Corps relies on its current inventory of radios 
to provide data connectivity down to the company level and below, such as the Portable 
Radio Component (PRC)-104, PRC-119, Mobile Radio Component (MRC)-138, MRC- 
145 and Enhanced Position Eocation Reporting System (EPERS). These are all strictly 
EOS radios that provide between 2.4 - 56 Kbps of data throughput. All of these radios 
are eventually going to be phased out by the Joint Tactical Radio System (JTRS) in 2008 
and beyond. JTRS is being designed to provide a flexible new approach to meet diverse 
warfighter communications needs through software programmable radio technology. 
There will be a significant increase in data throughput up to approximately 2 Mbps, and 
JTRS will provide reliable multi-channel voice, data, imagery, and video 
communications. As one can see, the process of getting more throughput to the 
battlefield is going to take some time with JTRS. Even when JTRS is fully fielded, the 
technologies evaluated in this thesis could complement the abilities of JTRS in the 
CoNDOR architecture. 

The authors will look at UOC, CAC2S, and CoNDOR, and how to improve LOS 
and BEOS communications in intra-nodal and inter-nodal environments throughout the 
thesis. The problem statements for UOC, CAC2S, and CoNDOR below will help further 
explain the reasons for conducting this research. 


5 http://www.marcorsvscom.usmc.mil/sites/pmcomm/trcl70.asp (April 2004). 
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2, Unit Operations Center (UOC) 

The UOC is a modular, scalable and mobile Command and Control System built 
to facilitate faster and more accurate decision making by Marine operational forces. It is 
currently going through operational testing with several fleet units. 

Battalion and Regiment level UOC use the same component. Regiment level 
UOC has a requirement to support a Coalition LAN and Video Teleconference (VTC) 
capability, which is not required for Battalion level. Also, the Regiment must support 15 
operators vice eight in the Battalion, and have two Visual Display Systems. To provide 
the additional power, tents, heating, and cooling, an additional Generator, Environmental 
Control Unit, and Tent (GET) trailer is required at Regiment. See Figure 1 for more 
detail of the setup.6 



Figure 1. UOC CONFIGURATION FOR INTRA-NODAL SETUP7 


The node-to-node communication between UOCs resembles the current COC to 
COC connectivity. Depending on the level of command, battalion and lower still rely on 

6 General Dynamics Decision Systems, “UOC Summary Brief’, 2003. 

7 General Dynamics Decision Systems, “UOC Summary Brief’, 2003. 
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LOS radios and UHF Satcom, while regiment and above use the MRC-142 and satellite 
based eommunieations means. The eurrent Marine Corps plan is to eonneet the COC and 
antenna hill via eables and wires. 

The Marine Corps understands the vulnerabilities of relying on LOS radios and 
MRC-142 for data and voiee connectivity. During OIF the Marine Corps regiments and 
divisions relied on satellite communications to maintain connectivity. One of these 
satellite systems was the Secure, Mobile, Anti-Jam, Reliable Tactical Terminal (SMART- 
T). SMART-T is a MILSTAR satellite-compatible communications terminal mounted on 
a High Mobility Multi-Purpose Wheeled Vehicle (HMMWV). It allows long-haul 
tactical communications for Digital Transmission Groups (DTG), Digital Subscriber 
Voice Terminal (DSVT), and individual encrypted subscribers, at data rates ranging from 
75 bps to 1.544 Mbps.8 

Even though some efforts have been made to address BLOS issues with node-to- 
node communications, there are several other wireless options available that will be 
brought out in this research. Based on visits by the authors over the past few months with 
the UOC offices at General Dynamics and Marine Corps Systems Command (MCSC), 
intra-nodal communications via wireless technologies are not included in the 
requirements for the system and are apparently not being looked at seriously. 

3, Common Aviation Command and Control System (CAC2S) 

The current MACCS functions with a Tactical Air Command Center (TACC), 
Direct Air Support Center (DASC), Tactical Air Operations Center (TAOC), Air Traffic 
Control (ATC), and Low Altitude Air Defense (LAAD) command and control centers. 
CAC2S will replace these legacy systems in three incremental builds, and it will provide 
common hardware and software to all users in the MACCS. CAC2S will be scalable, so 
it can be configured for air, ground, and afloat operations.9 

The MACCS agencies are dispersed throughout the battlefield with locations and 
distances being very unpredictable. So, the current structure uses a combination of 
MRC-142 and TRC-170 systems. The MRC-142 is strictly LOS and the TRC-170 can 

8 http://www.marcorsvscom.usmc.mifsites/pmcomm/smart t.asp (April 2004). 

9 Marine Corps Tactical Systems Support Activity, Program Support Division, “CAC2S Technical 
Briefing”, 13 February 2002. 
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extend out to distances of 100 miles due to the tropo scatter functionality of the system. 
Since there are not enough TRC-170s for each node located throughout the battlefield, 
MRC-142s are employed with retransmission sites set up on top of hills or mountains 
when LOS cannot be attained. Figure 2 shows how CAC2S is planning to communicate 
when the systems are fielded in 2007 and beyond. This is identical to how the current 
MACCS communicates. Thus, one can see the dangers of not upgrading the 
communication capabilities with the new system. 


Assumption: 

Engineering Deveiopmentai Modei 

(Based on the As-ls Marine Air Wing Equipment Lay Down) 



Figure 2. CAC2S FOR INTER-NODAL AND INTRA-NODAL COMMUNICATIONS 

The present plan between Raytheon (organization assisting the Marine Corps 
develop CAC2S) and Marine Corps Systems Command is to continue to connect the 
intra-nodal sites within each node by fiber optic cable. For example at the Air Support 
Node (ASN) node, the Processing and Display Subsystem (PDS) will be connected to the 
Communications Subsystem (CS) and the Sensor Data Subsystem (SDS) via a heavy- 
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duty fiber cable. There will also be fiber cable runs between the SDS and CS sites. This 
setup provides redundancy between all the sites, but it still is vulnerable and relies upon 
the cumbersome and expensive tasks of laying and burying wire. 

4, Command and Control On-the-Move Network, Digital Over the 
Horizon Relay (CoNDOR) 

The CoNDOR Capability Set is an Architectural Approach designed to bridge 
battlefield Command and Control over variable distance, either LOS or over-the-horizon 
(OTH). Figure 3 shows a CONDOR point-of-presence (POP) vehicle. It will facilitate 
communication with High Frequency (HF), Very High Frequency (VHF), Ultra High 
Frequency (UHF), UHF Satcom, and EPLRS radios. As JTRS evolves and is fielded, 
CoNDOR will be able to integrate these radios as well. Several technologies are being 
evaluated for CoNDOR’s satellite access to higher headquarters while it is stationary and 
on-the-move. 



Figure 3. CoNDOR POP VEHICLElo 


One problem that is inherent to the CoNDOR setup is that legacy LOS radios and 
eventually JTRS are being relied upon to provide data connectivity. These are all limited 
in throughput capabilities, for example legacy radios are less than 56 Kbps and JTRS is 
below 2 Mbps of throughput. The satellite communications system currently being 
looked at to connect the POP vehicle to higher headquarters is also limited in throughput 
(less than 1 Mbps). Several technologies evaluated in this research are viable options to 


10 https://www.quickplace.marcorsvscom.usmc.mil/CoNDOR (April 2004). 
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connect the CoNDOR POP vehiele at the battalion level down to the lower levels as well 
to connect the battalion POP vehicle to higher headquarters in a BLOS or OTH situation. 

In order to have a better understanding of the problem statements for UOC, 
CAC2S, and CoNDOR, detailed baekground information is given on eaeh program 
below. The authors were able to visit eaeh of the respective program offices at MCSC. 
In addition, they visited Raytheon’s CAC2S and General Dynamies’ UOC program 
offiees and Space and Naval Warfare Command (SPAWAR) Charleston, where several 
personnel are working with MCSC on UOC, CAC2S, and CoNDOR. This was all done 
for first hand knowledge of the programs and their progress. 


B, BACKGROUND INFORMATION 

The information discussed in the following paragraphs is designed to give the 
reader a general understanding of the programs involved in this thesis. By no means are 
the authors speaking on behalf of the program offices mentioned below. 

1. UOC 

a. Current 

The UOC is designed to provide Marine operational forces with command 
and control capabilities whenever and wherever Marines operate or fight, n The UOC is 
to provide the Ground Combat Element (GCE) commander with the neeessary hardware, 
software, equipment, and facilities to effectively command, coordinate, and eontrol 
MAGTE air in joint/multi-national operations. The UOC will be mobile, expandable, 
scalable, modular, command and control interoperable system in a HMMWV, C-130, or 
ship. The UOC will first be fielded to GCE, followed by the Command Element (CE), 
and the Combat Serviee Support Element (CSSE). The UOC facilitates command and 
control for the above elements. Eigure 4 depicts a Marine in the UOC. Eieutenant 
Colonel Tolbert from MCSC best captures the purpose of the UOC: 

The UOC program seeks to maximize the commander's deeision 
making superiority by providing digital tools and a fully integrated 
Combat Operations Center (COC) that uses common hardware 


11 UOC summary power point brief; General Dynamies 
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across the Marine Corps. This will result in increasing unit 
efficiency and combat effectiveness. 12 



Figure 4. MARINE IN THE UOC 


According to Headquarters Marine Corps, “The COC will provide the 
servers to host applications required by the commander. These applications include the 
Global Command and Control System (GCCS), Tactical Combat Operations (TCO), 
Intelligence Analysis System (IAS), Advanced Eield Artillery Tactical Data Systems 
(AFATDS), and Theater Battle Management Core System (TBMCS). The COC will 
connect to the Tactical Data Network for Digital Message System (DMS) services.”13 

The operational impact the UOC will have is that the commander and the 
commander’s staff will be able to receive a Common Tactical Picture (CTP) via data and 
voice communications. The UOC will have the capability of functioning as a 
reconfigurable, scalar, mobile, and deployable command and control system. 14 This 
capability will have a significant impact in Marine warfare by providing the foundation to 
facilitate command and control on the battlefield. 


12 http://www.gdds.com/uoc/uoc_digitalcombat.html; LtCol Donald D. Tolbert, Jr; Unit Operations 
Center: The Digital Combat Operations Center of the Future, Reprinted from Marine Corps Gazette, 
January 2003. 

13 http://hqinet001.hqmc.usmc.miFp&r/concepts/2001/PDF/UOC.pdf 

14 Ibid 
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b. Future 

The UOC is configured in predefined capability sets (CapSets). There are 
four CapSets: CapSet I is configured to support a Marine Expeditionary Force, CapSet II 
is configured to support a Division, CapSet III is configured to support a Regiment, and 
CapSet IV is configured to support a Battalion (Figure 5).i5 The estimated completion 
date for the initial operational capability is late 2004. In fiscal year 2005, twenty more 
units will be procured in order to support Operation Iraqi Freedom and technology 
inserts. 16 



Core Building Blocks Used to Build All 
UOC Capability Sets 



Echelon 

Capability Sets (CAP SETS) 


11 

111 

IV 

Alpha 


MEF (MEB 
BRAVO) 

MARFOR, 

FICeS, 

FSSG CSSOC, 
DIV, RGT 

MCSSD (4), MSSG, 
BN, MWSS, MEU, 

GS CSSD, DS CSSD 
(GCE), DS CSSD 
(FW) 2, DS CSSD 
(RW) 2 

Bravo 

MEF 

DIV,FSSG 
CSSOC 

RGT, MWSG, 
MEU, GS CSSD, 
DSCSSD 

BN, MAG, MWSS. 
MACG, 
SUPPORTING 
ESTABLISHMENT 




Set 1 


CipabUby Set III 

Capibili(> Set IV 


V •! 1 






Note: HMMWV are not included in 
these four Capability Sets. 

They are existing unit equipment. 


Figure 5. UOC CAPABIFITY SETS 


The UOC is designed with a T3 design: Tents, Trailers, and Transit Cases 
(Figure 6). The generator, environmental control unit, and tent are located on the GET 
(generator, environmental control unit, and tent) trailer. 17 


15 Detailed UOC power point brief; General Dynamics 

16 Conversation with Kevin Holt, USMC UOC team leader, MCSC 

17 Ibid; General Dynamics power point presentation 


11 

































Fast Deployment 





UOC is designed for maximum deployment 
flexibility using a ‘T3’ design: 

Tents, Trailers, Transit Cases 



Operational 
Trailer (OT) 


Equipment (SE) 


Generator, ECU, 
and Tent (GET) 


T3 design allows a wide range of deployment options 


Figure 6. T3 DESIGN 


The operational trailer (OT) is the key eomponent in the T3 design. The 
operational trailer has a raek strueture that supports and provides a seeure network, a non- 
seeure network, uninterrupted power supply, eight operator workstations, intereom, 
publie address system, and on-the-move capability (via EPLRS, VRC-92, and PSC-5). 
The transit cases do not need to be removed from the trailer, hence, reducing the setup 
time. The transit cases are interconnected with cable harnesses that are permanently 
installed on the rack. All cable connectors are accessible either from the front of the 
equipment or from the rear with sufficient cable service loops. The supplemental 
equipment provides a repeatable load plan and the capability of reusable harnesses and 
straps. 

2. CAC2S 

a. Current 

This program is to provide the Aviation Combat Element (ACE) 
commander with the necessary hardware, software, equipment, and facilities to 
effectively command, coordinate, and control MAGTE air in joint/multi-national 
operations. CAC2S is a mobile, expandable, scalable, modular, full command and 
control interoperable system in a Highly Mobility Multi-Purpose Wheeled Vehicle 
(HMMWV), C-130 aircraft, or ship. CAC2S provides a common operational picture for 
air operations, weapons control, communications, sensors, and other displays. The key 
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feature of the program is that it functionally replaces dissimilar stovepipe systems 
currently utilized by the Marine Aviation Command and Control System (MACCS). 
Additional features are that it reduces the footprint and lift, while providing a complete 
and coordinated modernization effort capable of supporting Expeditionary Maneuver 
Warfare (EMW).i8 See Eigure 7 for illustration. 



ASPARCS 


Eigure 7. CAC2S OVERVIEW 


CAC2S provides the means to revolutionize the equipment base and 


operational concepts of the MACCS to support Operational Maneuver Erom the Sea 
(OMETS). CAC2S will provide the MAGTE commander with the mission critical 
support system required to integrate aviation and ground combat operations in support of 
the Marine Corps’ operational objective. CAC2S will provide the ACE commander and 
battle-staff with the capability to communicate with higher, adjacent, and subordinate 
units, as well as the ability (through subordinate MACCS agencies) to exercise real-time 
positive control, coordination, and direction of MAGFT and joint air assets. CAC2S 
components will operate from aerial platforms, amphibious shipping and from C2 

18 CAC2S SFR Brief: October 21-22, 2003 
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agencies ashore. In other words, CAC2S will operate on land, at sea, or from the air to 
support Marine Corps war fighting concepts for the 21st Century. 19 


CAC2S provides an operational impact in conjunction with MACCS 
organic sensors and weapon systems in order to support the tenets of Expeditionary 
Maneuver Warfare and fosters joint interoperability with Department of Defense’s 
command and control systems. CAC2S will replace legacy C2 systems in the following 
Marine aviation C2 elements: Tactical Air Operations Center (TAOC), Tactical Air 
Command Center (TACC), Direct Air Support Center (DASC), Marine Air Traffic 
Control Detachment (MATCD), and Low Altitude Air Defense Battalion (LAAD BN).20 
b. Future 

CAC2S will be comprised of modules and subsystems. Hardware 
components for CAC2S will be modular and man-portable. According to Marine Corps 
Tactical Systems Support Activity (MCTSSA): 

The CAC2S modules are scalable to meet mission requirements. 

The modules will be assembled to create an operational node. The 
core software of the CAC2S will include all of the functions 
common to all current MACCS agencies, including the ACE 
requirement for aviation C2 planning. Mission unique functions 
will be configurable and selectable from every workstation. The 
CAC2S will interface with, but not replace, radios, air defense 
weapons, and sensors organic to the MACCS .21 

The Raytheon estimated completion date for the initial operational 
capability is Eebruary 2007. The program status, according to the CAC2S brief, is as 
follows: 


The CAC2S and UOC programs are being developed in parallel to 
eventually achieve a common MAGTF Operations Center solution. 
CAC2S is being developed in an evolutionary acquisition strategy 
in four increments. Increment I will replace the functionality of 
the TAOC and will baseline the core information fusion and 
management function common to all increments and eventually all 
MAGTF Operation Centers. Increment II will replace TACC and 
DASC nodes. Increment III will achieve integration between 

19 Power point brief; MCTSSA CAC2S BRIEF 13 FEB 02 

20 http ://hqinet001 .hqmc .usmc .miFp&r/concepts/2000/PDFs/Chapter4/ch4_p 111 _CAC2 S .pdf 

21 http://www.mctssa.usmc.miFPSD/CAC2S%20fact%20sheet.pdf 


14 



CAC2S and the Air Surveillance and Precision Approach Radar 
Control System (ASPARCS) for Air Traffic Control functionality. 
Increment IV is the transition to the complete MAGTF Operation 
Center functionality. CAC2S is an ACAT III program currently in 
the definition and risk reduction development phase .22 

MCTSSA captures the different increments in Figure 8. 



CAC2S Incremental Approach 


Increment I - Hardware and 
software replacement for the core 
MACCS requirements and the 
Tactical Air Operations Center 

(TAOC) functionality 
Increment II - Tactical Air 
Command Center (TACC) 
functionality and the Direct Air 
Support Center (DASC) 
functionality 

Increment III - Marine Air Traffic 
Control (ATC) C2 Integration 

Increment IV - MAGTF OC 
functionality 

Marine Corps Tactical Systems Support Activity, Program Support Division 



Figure 8. CAC2S INCREMENTAL APPROACH 


3. CONDOR 

a. Current 

According to MCSC, “CoNDOR capability set is a program of record that 
provides the ability to link dispersed OTH and/or BEOS operators.”23 

In order to better understand CoNDOR, the reader needs to understand 
how Marine Corps communications works. Marine Expeditionary Force (MEF) and 
MSCs like the Division, Wing, and Force Service Support Group Headquarters have 
historically had reliable connectivity. The MEF and MSCs have been connected via large 
satellite networks. Telephone connectivity, a military version of public switched 
telephone network, is then built into the satellite networks. Data connectivity for 

22 www.hqinet001.hqmc.usmc.mil/p&r/concepts/2002/PDF/CH3_Part3/ch3%20part%203%20CAC2S.pdf 
23 Lieutenant Colonel J.D. Wilson, “Draft CoNDOR C4ISP”, MCSC, March 2004 
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classified and unclassified networks is provided via a Tactical Data Network, wtiioli 
usually uses the satellite links. The major limitations for MET and MSCs are the laek of 
satellite throughput available to support the high bandwidth demand and the loss of 
eommunioations when the MSC commander displaces to a new loeation.24 

The infrastrueture for maneuvering commands like Companies, Batteries, 
or mobile Combat Service Support Detaehments, is limited to LOS radios and small 
amounts of bandwidth availability. These limited eommunications are means by which 
the maneuvering eommands communicate to their Battalions, Regiments, or higher 
headquarters. Data travels across the battlefield via EPLRS, or through a point-to-point 
system using modems such as ViaSat. Once the information reaehes the MSC level, it is 
passed along the MSC communication links. The major limitations have been the limited 
bandwidth provided by the taetieal radios and the lack of an OTH capability. Through 
the efforts of the Office of Naval Research (ONR) and MCTSSA connectivity for the 
maneuver forees from the ship to the objective area has been provided by a 
eommunieations bridge via the CoNDOR gateway (Figure 9). The CoNDOR gateway 
uses EPLRS to establish the eommunications bridge, but there are units that do not have 
EPLRS. For these units a Point of Presence Vehicle (POP-V) provides eonnectivity to 
the MSC. The data is very limited however, due to the throughput of the taetieal radio, as 
described in the problem statement above. 


24 Lieutenant Colonel J.D. Wilson, “CoNDOR Overview”, MCSC, power point presentation Mareh 
2004 
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CONDOR “Gateway’ 





The CONDOR Gateway: 

Purpose: Connects EPLRS Communities over distance. 

-EPLRS Node 
-C2PC Gateway 

-Over the Horizon connection (INMARSAT, Iridium, TACSAT) 



EPLRS Community 


EPLRS Community 


But what can we provide 
for the 

Units that do not have 
EPLRS? 


Figure 9. CONDOR GATEWAY 


b. Future 

The CoNDOR gateway consists of an EPLRS node, a Command and 
Control Personal Computer (C2PC) gateway, and OTH connectivity (INMARSAT, 
Iridium, or TACSAT). In a PoP-V the gateway will consist of tactical radios 
(SINCGARS, Have Quick II, TACSAT DAMA, HP, HP ALE, EPLRS), C2PC gateway, 
and OTH connectivity (Pigure 10). 
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The CoNDOR PoP-V will provide the eapability of extending the network 
via tactical radios. Additionally, the CoNDOR PoP-V will give insight on how to 
configure the architecture for the Joint Tactical Radio System (Figure 11). 



Figure 11. USMC JTRS CONDOR POP-V 


Integration capabilities for CoNDOR are being conducted in a universal communications 
interface module (UCIM). The UCIM is a modular component set that will configure 
vehicular power to communications systems; load and configure all radios (legacy and 
JTRS); load and tune the antennas; provide a keyboard, video, and mouse functionality 
from any seat; provide a central processing unit to host applications (C2PC gateway, 
SPEED, etc.); and create an enclave, coupling C2 systems with radios. Other capabilities 
are being developed in a CoNDOR JUMP C2. In the CoNDOR JUMP C2, the 
commander will have continuous connectivity even when the unit displaces from one 
location to another. The continuous connectivity increases situational awareness and 
enhances the commanders’ command and control capabilities (Figure 12). 
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A CONDOR “Jump C^” 



Figure 12. CONDOR JUMP C2 


This section discussed the background of the programs that are addressed 
in this thesis. The following sections will further explain the statement of the problem 
and the methodology used to approach it. 
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II. RESEARCH METHOLOGY AND FIELD TESTS 


Multiple technologies were evaluated for potential use in three Marine Corps 
programs: UOC, CAC2S, and CONDOR. The authors used a “building block” approach 
to become familiar with the research topic and available technologies in the commercial 
sector. 

First, the authors visited Marine Corps Systems Command, Space and Naval 
Warfare Systems Command - Charleston, Office of Naval Research, Marine Corps 
Warlighting Laboratory, and Marine Corps Tactical Systems Support Activity to become 
familiar with the Marine Corps programs and current research being conducted. In 
addition, the authors visited private company laboratories to observe applicable 
technologies working in an operating environment. Finally, the authors visited the UOC 
program office at General Dynamics Decision Systems (GDDS) in Scottsdale, AZ and 
the CAC2S program office at Raytheon in San Diego, CA to become familiar with the 
research being done by government contractors to exploit the wireless communications 
industry. 

Following these visits, four field-testing events were planned over a five-month 
period starting in November and ending in March. The field events began with a 
“backyard exercise” in the Monterey, CA area to become familiar with various network 
configurations and some of the technologies being evaluated. Next, in January, the 
authors traveled down to GDDS to work with the UOC team and demonstrate the 
different technologies to them. The authors then went to Raytheon in February in order 
for the CAC2S team to see what technologies were available for possible intra-nodal and 
inter-nodal communications. Finally, in March the authors traveled to Camp Roberts, 
CA to conduct a realistic field-testing event that simulated a CONDOR scenario. In 
order to facilitate the research the authors utilized the Naval Postgraduate School’s 
Mobile Research Facility (MRF). This is a 3 3-foot Recreational Vehicle that was 
converted into a mobile Network Operations Center. Connectivity was tested from this 
platform in order to simulate Command Center to Antenna Hill and CAC2S node to 
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CAC2S node links. The data obtained from these testing events was used by the authors 
to evaluate various eommercial technologies for potential use in Marine Corps 
operations. 

Marketing and technical literature from all the companies were also reviewed to 
include system/subsystem specifications, test evaluations, and engineer assessments. 

Finally, the visits to program offices and private companies, was combined with 
the testing and document research, to formulate recommendations for future UOC, 
CAC2S, and CONDOR communications architectures. 

A. FIELD TEST #1 (FORT ORD AND BIG SUR, CA) 

The purpose of the first experiment was to become familiar with Free Space 
Optics (FSO) Equipment and 802.11 link equipment in order to establish a baseline for 
follow-on testing for transformational wireless communications technologies for UOC, 
CAC2S, and CoNDOR. The methodology used was to establish two Local Area 
Networks (LANs), one at a fixed site (Ligure 13) and one at the MRL (also known as 
Nemesis). These two LANs were then linked using two different LSO systems, (ILONA 
17 & 18 November and Lightpointe 20 & 21 November). 802.11 wireless technology 
was also used during both test periods. These tests are described in the sections that 
follow. 
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Figure 13. FIXED SITE AT BIG SUR 


Some of the anticipated results were to be able to develop a more thorough 
understanding of the limitations, set up, throughput, and mobility of FSO and establish a 
methodology for future experiments. This was a “kick the tire” experiment where the 
primary focus was to establish a wireless link between two sites and gather information 
such as power, special connectors, and logistical requirements in order to conduct an 
experiment. 

1, Line-of-Sight (LOS) 
a. fSONA 

IBONA specializes in Free Space Optics communications. The company 
is based in British Columbia, Canada. This FSO company was eager to assist during this 
testing event, as well as each of the others. Their team consisted of the following people: 
Mike Corcoran, Vice President Sales; Grant Merkley, Inside Sales; Pablo Bandera, 
Product Manager; and Sean Dante, Field Technician. The Naval Postgraduate School 
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(NFS) students primarily involved were Captain Gilbert Gareia (USMC), Captain David 
Joseforsky (USMC), Lieutenant Albert Seeman (USN), and Lieutenant Jesus (Manny) 
Cordero (USN). 

Testing was eondueted on November 17-18, 2003 for lEONA. On 17 
November, a test was eondueted at a distanee of 580 meters in an urban environment at 
Fort Ord, California, and on 18 November testing was eondueted at Big Sur, California, 
in order to establish a longer link (850 m) than the one used at Fort Ord. The equipment 
used was the SONAbeam 155-M model (Figure 14), whieh delivered an OC-3 data rate 
(155Mbps), but during the experiment the link was running at Fast Ethernet speeds (100 
Mbps). This produet provides a full duplex transmission at the physieal layer with four 
independent lasers, drivers, eoolers, and eooler eontrollers. It eomes with a east 
aluminum housing, yoke, and mount. The fiber optie interfaee is a Single-Mode or 
Multi-Mode fiber, SC terminated. The SONAbeam 155-M system was designed to 
mount to any vertieal pole of diameter 2.5" to 4.5". The FSO transeeivers were set up on 
a ten-foot steel pole with three legs to stabilize the pole. Eaeh leg and the pole weighed 
roughly fifty pounds. This allowed the ESO link to be very stable. These pole mounts 
were not INONA's, and were aetuahy bigger than they really needed to be. Other means 
are being explored by IBONA to find a mount that is more field expedient and suitable 
for the Marine Corps. 
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Figure 14. SONABEAM 155M MODEL 


The weather conditions for this testing were ideal, with clear skies and 
calm winds. Figure 15 depicts an overview of the LAN configuration showing the 
physical layout of the testing equipment and the IP addresses for each piece of gear in the 
network. 
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Overall View Nov 17-18 


Remote 

(Gil) 

Fixed Site 


R.V. Sit© (Dave) 



Figure 15. OVERVIEW DIAGRAM fSONA EXPERIMENT 


ISONA representatives set up lEONA’s FSO equipment. On 17 
November, they demonstrated the setup of the equipment and also showed the NPS team 
how to align the link. The total set up time was one hour including a detailed explanation 
to the users on how to set up the gear properly. Seasoned field technicians from lEONA, 
on previous occasions, have set up the gear and had it operational within 30 to 45 
minutes. 

Each day, media converters were placed between the ESO link and the 
WAN switches because the Cisco 2950 switches being used did not have the appropriate 
interface to connect directly to the ESO link. Single-mode fiber was interfaced from the 
FSO link to the media converter. From the media converter, RJ-45 cable was interfaced 
to the Cisco 2950 Switch. 

On 18 November, an 850 meter link was established at Big Sur from the 
NPS facility (fixed site) to the base of a mountain where Nemesis was located (Figure 
13). Captain Gilbert Garcia and Captain David Joseforsky set up the lEONA equipment 
in order to demonstrate the ease of equipment setup. Captains Garcia and Joseforsky 
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were able to set up and establish the link within 60 to 90 minutes. This included aligning 
and fine-tuning the lasers. Alignment of the lasers consisted of centering the distant 
optical head in the cross hairs of a riflescope. Fine-tuning of the lasers was conducted by 
turning screws on the optical link head. A voltage reading, a measurement corresponding 
to the received optical power of the terminal of the distant link’s sensitivity, was read on 
a voltmeter. This reading was used to fine-tune the alignment. 

The data collected from lEONA’s FSO link was limited due to network 
issues. The initial plan was to establish streaming video between two computers on 
different networks, and measure the throughput. The authors were unable to stream 
video between the LANs because of equipment limitations. Next, video sharing was 
attempted with less than desirable results. As it turned out, only measured transmission 
between the two networks was during file sharing. Mapping a network drive and 
connecting to the remote computer on the different network accomplished this task. The 
table below gives the data collected from ISONA’s FSO link (Table 5). 


17-NOV-03 







Run No. 

Media 

Size 

Time 

Type 

Throughput 

Packet Loss (%) 

1 (Net Meeting) 

FSO 

7MB 

30 sec 

1:01 

1.2MB 

0% 

2 

FSO 

36MB 

3 min 

1:01 

1.2MB 

0% 








18-NOV-03 







Run No. 

Media 

Size 

Time 

Type 

Throughput 

Packet Loss (%) 

1 (File Share) 

FSO 

6.5MB 

30 sec 

1:01 

35MB 


2 

FSO 

14/3 5MB 

10s/45s 

2:01 

6.26MB 

files at same time 


Table 5. RAW DATA FROM FSONA 
b. Lightpointe 

Lightpointe is a FSO company based in San Diego, California. The team 
was top-notch and was very customer-oriented. The members of this organization were 
Jim McGowen, Director of Sales; Albert Borquez, Senior Network Engineer; and Steve 
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Hane, VP Business. The NPS students primarily involved were Captain Gilbert Garcia, 
Captain David Joseforsky, LT Albert Seeman, and LT Jesus (Manny) Cordero (Figure 
16). 



Figure 16. TEAM LIGHTPOINT AND NPS STUDENTS 


Testing with Lightpointe was conducted on November 20-21, 2003. The 
setup was straightforward and simple. As before, two LANs were established, one at the 
fixed site and the other at the MRF. The distance between the two sites was 850 meters. 
The diagram below (Figure 17) gives an overview of how equipment for the experiment 
was configured. 
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Overall View Nov 20-21 


Remote 

(Gil) 

Fixed Site 


R.V. Sit© (Dave) 



Figure 17. OVERVIEW DIAGRAM LIGHTPOINTE 


On 20 November, the primary focus was to see if the outer switch would 
be able to handle both 802.11b and ESO simultaneously. Eirst, Eightpointe explained to 
the students how to set up the equipment and demonstrated the ease of equipment setup 
for the network. 

Eightpointe brought their ElightStrata-G Ely Away Kit. The ElightStrata 
(Eigure 18) has a data rate of 1.25 Gbps. It provides full duplex transmission at the 
physical layer with a flexible distance of 1 meter (can transmit any distance between one 
meter and 4,800 meters). It features automatic beam tracking and automatic gain control. 
It has a Multi-mode fiber interface, but a Single-mode fiber interface is available. The 
ElightStrata took 5 minutes to acquire signal (both ends communicating to each other) 
and about 20 minutes of fine-tuning (optimizing the signal between the two ends). 
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Figure 18. LIGHTPOINTE FLIGHTSTRATA MODEL 

Albert Borquez, Lightpointe’s Senior Network Engineer; LT Manny 
Cordero, NPS; and Captain Dwayne Laneaster (USMC), NPS, eonfigured the switches 
and routers. Data was collected to see if the switch was able to handle 802.1 lb and FSO 
simultaneously. Files being sent were similar to files that might be used on the battlefield 
between two units (i.e. data fdes composed of Word documents, Power Point documents. 
Excel spreadsheets, PDF documents, and text documents). A 6 Megabyte fide was sent 
and recorded with a throughput of 1 Mbps using SolarWinds (see annex for further 
explanation of SolarWinds). The following raw data obtained on November 20 shows 
the throughput results when comparing 802.1 lb and Lightpointe’s FSO (Table 6). 
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Run No, 

Media 

Size 

Time 

From 

To 

Type 

Throughput 

Packet Loss (%) 

1 

FSO 

324M 

1'32" 

1.3 

3.3 

1:01 

34M 

0 

2 

RF 

4M 

1' 15" 

1.3 

3.3 

1:01 

500K 

18 

3 

FSO 

147M 

45" 

1.3 

3.3 

1:01 

33M 

0 

4 

FSO 

147M 

41" 

3.3 

1.3 

1:01 

42M 

0 

5 

FSO 

324M 

1' 

3.3 

1.3 

1:01 

timed-out 

time-out 

6 

RF 

4M 

34" 

3.3 

1.3 

1:01 

1.3M 

21 

7 

RF 

16K 

5" 

1.3 

3.3 

1:01 

none 

20 

8 

RF 

64K 

3" 

1.3 

3.3 

1:01 

none 

19 

9 

RF 

70K 

2" 

1.3 

3.3 

1:01 

none 

18 

10 

RF 

123K 

4" 

1.3 

3.3 

1:01 

none 

17 

11 

RF 

144K 

3" 

1.3 

3.3 

1:01 

none 

16 

12 

RF 

147K 


1.3 

3.3 

1:01 


15 


Table 6. RAW DATA FROM LIGHTPOINTE FSO AND RF 


On 21 November, Captain Garcia and Captain Joseforsky established the 
link on their own. The initial link setup took approximately 5 minutes and fine-tuning 
took an additional 30 minutes. This demonstrated how quickly individuals with little 
training could deploy the system. The focus was on FSO time latencies. The results of 
the second day of testing are as follows (Table 7): 


Run No, 

Media 

Size 

Time 

From 

To 

Type 

Fhroughpui 

Packet Loss (%) 

13 

FSO 

324M 

1' 11" 

3.3 

1.3 

1:01 

43M 

0 

14 

FSO 

89M 

19" 

3.3 

1.3 

1:01 

43M 

0 

15 

FSO 

89M 

17" 

1.3 

3.3 

1:01 

46M 

0 

16 

FSO 

32M 

6" 

3.3 

1.3 

1:01 

36M 

0 

17 

FSO 

32M 

7" 

1.3 

3.3 

1:01 

43M 

0 

18 

FSO 

26M 

4" 

3.3 

1.3 

1:01 

31M 

0 

19 

FSO 

26M 

6" 

1.3 

3.3 

1:01 

36M 

0 

20 

FSO 

20M 

5" 

3.3 

1.3 

1:01 

25M 

0 

21 

FSO 

20M 

4" 

1.3 

3.3 

1:01 

14M 

0 

22 

FSO 

4M 

2" 

3.3 

1.3 

1:01 

5.8M 

0 

23 

FSO 

4M 

2" 

1.3 

3.3 

1:01 

5.8M 

0 

24 

FSO 

648M 

2' 20" 



N:N 

44M 

0 


Table 7. RAW DATA FROM LIGHTPOINTE FSO 


The final portion of the Lightpointe test was to physically cover different 
portions of the FSO transceiver lens and annotate the results. The purpose of the test was 
to determine how much of the optical lens needed to be exposed in order to effectively 
transfer data between the two LANs. This test was not conducted with ffiONA due to 
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time limitations. While transferring a 147 Mb file between two eomputers on two 
different LANs, a 25Mbps throughput was produced by covering one of the four 
transmitting lasers. The entire optical head was then covered until the signal was lost. 
Once the signal was lost, data stopped transferring and it took 20 seconds to reacquire the 
signal after the laser heads were uncovered (the 20 second interval is the minimum time 
Cisco products need in order to determine what is currently connected in the network). 
When two laser heads were covered, a 45 Mbps throughput was produced across the 
network. The entire optical head was covered again until the signal was once again lost. 
At that point, it took 20 seconds to reacquire the signal. When three laser heads were 
covered, a 45 Mbps throughput was produced across the network. The signal was lost 
when the entire optical was covered. Once again, the signal stopped transferring data, 
and it took 20 seconds to reacquire the signal. By walking in front of the laser twice, the 
signal was lost and it took 30 seconds to reacquire the signal. By passing a lid quickly in 
front of the laser, the signal was lost. Finally, after passing a water bottle in front of the 
laser, the signal experienced a 13 percent packet lost. The signal remained acquired 
throughout the water bottle test. 

Conclusions and recommendations from this experiment can be found in 
the Conclusions and Recommendations portion of this thesis. 

c. 802 . 11 b 

The Naval Postgraduate Students primarily involved were Captain Gilbert 
Garcia, Captain David Joseforsky, LT Albert Seeman, and LT Jesus (Manny) Cordero. 
The time period of this testing experiment was November 17-21, 2003. 

The equipment used for this testing was the Linksys Access Point 
(WAPll). The goal was to test the throughput of 802.11b with yagi and parabolic 
antennas connecting two Linksys access points. The access points were configured in 
bridging mode for this portion of the testing. On 17 November, the 802.1 lb link was set 
up at 550 meters with yagi antennas. Initial connectivity was established with these 
antennas in order to connect the two networks. Parabolic antennas were erected next to 
establish connectivity at 550 meters connecting the two LANs. On 18 November, the 
same configuration was used at 850 meters in order to share files via NetMeeting. 

SolarWinds, a product used to measure throughput, determined that NetMeeting had a 
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1.27 Mbps limit on the amount of maximum throughput. Table 8 below represents the 
raw data eollected for this portion of the experiment. 


17-NOV-03 







Run No. 

Media 

Size 

Time 

Type 

Throughput 

Packet Loss (%) 

1 

Yagi 

20K 

2 sec 

1:01 



2 

Yagi 

164K 

5 sec 

1:01 



3 

Yagi 

7MB 

n/a 

1:01 

526K 

13-27% 

4 

Parabolic 

7MB 

45 sec 

1:01 

1.27MB 


5 

Parabolic 

35MB 

n/a 

1:01 










18-NOV-03 







Run No. 

Media 

Size 

Time 

Type 

Throughput 

Packet Loss (%) 

1 (Net Meet) 

Parabolic 

35MB 

n/a 

1:01 

736K 


2 (Net Meet) 

Parabolic 

7MB 

1'23" 

1:01 

486K 


3 

Parabolic 

35MB 

6 min 

1:01 



4 

Parabolic 

300MB 

too long 

1:01 

792K 


5 

Parabolic 

7MB 

1 min 

1:01 

800K 



Table 8. RAW DATA YAGl AND PARABOLIC ANTENNAS 


The type of cable used for the experiment was coaxial cable along with the 
Comscope WBC series cable assemblies. The 3/8 inch WBC-400 & WBC-400R 50 
coaxial cable assemblies have a maximum bending radius of two inches or fifty 
millimeters. Attenuation at 2500MHz = 6.8dB/100feet; 3.4dB/50feet; 1.7dB/25feet; 
.17dB/2.5ft. 

Parabolic and yagi antennas were used during the testing. In order to 
maximize the strength of antenna propagation pattern, it was important to understand the 
polarization in relation to the positioning of the element with respect to horizontal versus 
vertical beam widths. When the grid antenna was positioned with horizontal polarization, 
the horizontal beam width was eight degrees. The respective elevation beam width was 
three degrees. The parabolic antenna tested was the HyperGain Reflector Grid Antenna, 
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HG2424G25, which is seen in (Figure 19). The specifications on the antenna are 
provided below in Table 9. 


The two polarities are illustrated below: 



Polarity Polarity 

Figure 19. PARABOLIC ANTENNA 


Electrical Specifications 


Frequency 

2400-2500 MHzl 

Gain 

24 dBi 

-3 dBi Beam Width 

8 degrees 

Cross Polarization Rejection 

26 dBi 

Front to Back Ratio 

24 dB 

Sideiobe 

-20dB Max 

impedance 

50 Ohm I 

Max. input Power 

50 Watts 

VSWR 

< 1.5:1 avg. [ 


Mechanical Specifications 


Weight 

4.8 lbs. (2.18 kg) 

Grid Dimensions 

39.5 in (100 cm) x 23.5 in (60 cm) 

Mounting 

2 in. (50.8 mm) diameter mast max. 

Eievation Angie 

Oto +10 degrees 

Operating Temperature 

-45° C to +85° C 


Table 9. PARABOLIC SPECS 
25 http://www.hyperlinktech.com/web/pdf/hg2424g.pdf 
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The yagi antenna tested was a HyperGain Radome Enclosed Yagi antenna, 
HG2415Y26 (Figure 20). The beam width appeared to be 30 degrees regardless of 
polarization (Table 10). 






Figure 20. YAGI ANTENNA 

Electrical Specifications Mechanical Specifications 


Weight 

1.8 lbs. 

Length 

19" length x3" diameter 

Radome Material 

UV-inhibited Pdymer 

Mounting 

2 3'8"dia. mast max. 

Polarization 

Vertical 

Wind Survival 

>150 MPH 


Frequency 

2400-2500 MHz 

Gain 

14.5 dBi 

-3 dB Beam Width 

30 degrees 

Impedance 

50 Ohm 

Max. Input Power 

50 Walts 

VSWR 

< 1.5:1 avg. 


Table 10. YAGI SPECS 


2, Beyond Line-of-Sight (BLOS) 

No BEOS testing was conducted during this experiment. See Field Test #3 
(Raytheon) and Field Test #4 (Camp Roberts). 

3, Over-the-Horizon (OTH) 

No OTH testing was conducted during this experiment. See Field Test #3 
(Raytheon) and Field Test #4 (Camp Roberts). 

B. FIELD TEST #2 (GENERAL DYNAMICS) 

Students from NPS conducted thesis research for Marine Corps Systems 
Command on January 6-9, 2004 with General Dynamics Decision Systems (GDDS) in 
Scottsdale, AZ. The actual testing was done on Papago’s Arizona National Guard base 
three miles from GDDS. The following NPS students were involved in the testing event: 

26 http ://www.hyperlinktech.com/web/pdf/hg2415y.pdf 
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Captain David Joseforsky, Captain Gil Garcia, LT Manny Cordero, LT A1 Seeman, 
Captain Dwayne Laneaster, and Captain Chris Cox (USMC). 

The students. General Dynamies personnel, and several vendors participated in 
taetieal communieations testing for the UOC being built by General Dynamies. The 
testing compared current state-of-the-art commereial capabilities in the following areas: 
1) Wireless teehnologies, 2) Operational ease of use, 3) Power and environmental 
eonsiderations, and 4) Communieation bandwidths. Eaeh teehnology was evaluated for 
COC to COC (inter-nodal) and COC to Antenna Hill (intra-nodal) modes of operation. 

The ultimate goal of this testing event was to determine whieh teehnologies 
inerease throughput on the battlefield for the UOC program. The following state-of-the- 
art wireless teehnologies were tested: Free Spaee Opties, 802.11b (over SeeNet-11), 
802.16, and Mierowave Link. Voice over Internet Protoeol (VoIP) was implemented in 
the loeal area networks to test whieh teehnologies handled it best. Next, the students 
demonstrated an OTH eapability provided by eombining four Iridium satellite ehannels, 
similar to the Expeditionary Tactical Communications System. Over this link, the 
Iridium Inverse Multiplexer and Compression Algorithm, being developed by Dr. Glen 
Abousleman at Arizona State University, was utilized. Finally, establishing a eovered 
network with General Dynamics’ In-Line Network Eneryptor, KG-235, was a testing 
objeetive. 

Figure 21 illustrates the established network at this testing event. Since there 
were two LANs in this Wide Area Network, the students deeided to eonfigure three 
separate subnets. The MRF setup was a 192.168.1.x subnet, the remote site was 
192.168.3.x, and the established link between the two networks was 192.168.2.x. Thus, 
the Ciseo 3745 routers on the edge of the LAN were configured to have the Ethernet port 
eonneeted to the link as a 192.168.2.1/2 IP address, and the port conneeted to the switeh 
within the LAN was assigned 192.168.1.1 for the remote site and 192.168.3.1 for the 
MRF. Next, the Ciseo Call Manager Server and the IP Phones were assigned an IP 
address according to their respeetive subnet as they came online. The Cisco 3550 
switches and DSUs did not have an IP addresses assigned to them. 
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Radio Frequency Module^FM) v3 


IMUX 


IMUX 


'tisco Router 
. 3745 . 


'cisco Router 
. 3745 ^ 


Call Manager 


Cisco Switch 3550 


Solar Winds 


Call Server/ 
DHCP Server 


IP Phone 


Ca Manaoer 


nacj 


Cisco Switch 3550 ^^ ^ ^ 


DSU 


Call Server/ 
DHCP Server 


IP Phone 


192.168.1.2/24 192.168.1.3/24 


Figure 21. GENERAL DYNAMICS TESTING NETWORK DIAGRAM 


The above figure conveys a network without encryption, except when using 
SecNet-II over 802.1 Ib. Since the original goal was to establish a covered network, 
toward the end of the week. General Dynamics’ In-Line Network Encryptor, KG-235, 
was inserted into the network in place of the Cisco 3745 Routers to achieve a covered 
network. Obtaining this covered network was unsuccessful due to configuration issues 
with the KG-235. Thus, the entire testing event, except SecNet-11 testing, was done 
without encryption. 

To show the capabilities of each evaluated technology as far as physical distance, 
the technologies are broken down into three different categories; LOS, BEOS, and OTH. 

1, Line-of-Sight (LOS) 
a. SecNet-11 

SecNet-11 is a product developed by Harris Corporation. It is a secure, 
NSA Type 1 and EIPS-140 compliant encryption, wireless local area network interface 

37 






































card. National Security Agency’s certification of the SeeNet-11 card does not include the 
system software/hardware residing on the host, or the software contained on the CD 
packaged with the SecNet-11. The SeeNet-11 eard provides secure eommunication of 
data as well as souree and destination addresses without the requirement for a hardwired 
network. The card operates in the unlicensed 2.4 GHz Instrumentation, Science, and 
Medical (ISM) band and will operate aceording to the 11 Mbps Institute of Eleetrieal and 
Eleetronics Engineers (IEEE) 802.11 protocol with the additional processing time and 
delay assoeiated with enerypting the header information.27 

The SeeNet-11 uses standard DOD keying material. It accepts only a 
single red key using the DS-102 protoeol. The device ean be loaded with 
UNCEASSIEIED, CONEIDENTIAL, or SECRET keys. SecNet-11 is not currently 
approved for TOP SECRET. A single red key is loaded into the card via a Data Transfer 
Device (DTD) (i.e., AN/CYZ 10) using the DS-102 protocol. The same key must be 
loaded into all loeal SecNet-11 deviees that will intercommunicate.28 

The SecNet-11 testing for this event was done at 500 meters. As seen 
above in the General Dynamics Testing Diagram, Eigure 21, the 802.1 lb over SecNet-11 
was set up in a point-to-point link. SecNet bridges were used to transmit point-to-point. 
Eaeh bridge aetually takes one of the SecNet cards. Thus, the signal was encrypted 
between both bridges. The rest of the network was wired loeally, so the network was 
relatively secure. Next, the parabolic antenna described in field test #1 was used as the 
remote antenna, and it was connected to the SeeNet card on the bridge via an N-type 
eable. A special connector was needed that could screw into the SecNet card on one end 
and the other end to the N-type eable. Eurthermore, the connection between the bridge 
and the Cisco 3745 router was a CAT-5 cable. Einally, speed settings for the ports on the 
Ciseo routers and switehes needed to match the speed of the SecNet bridge. The routers 
and switehes were set to speed 10 vice speed 100 as was done with all the other 

27 Richard C. Shaeffer, Jr., Information Assurance Deputy Direetor, NSA, “Interim Operational 
Systems Seeurity Doetrine for the SeeNet-11 Wireless Loeal Area Network (WLAN) Interfaee Card”, 
Oetober 2002. 

28 Richard C. Shaeffer, Jr., Information Assuranee Deputy Direetor, NSA, “Interim Operational 
Systems Seeurity Doetrine for the SeeNet-11 Wireless Loeal Area Network (WLAN) Interfaee Card”, 
Oetober 2002. 
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technologies tested in order to prevent a configuration mismatch in the line speed. The 
devices were set for full duplex. 

In order to change the settings on the bridge, the authors needed to connect 
a computer to a switch or hub via CAT-5 cable and then from the switch or hub to the 
bridge via CAT-5. Then they could view the Graphical User Interface provided by the 
software that comes with the bridge. Since the bridges needed special settings, one 
bridge was set as ‘Master’ and the other bridge was set as ‘Slave’. For this testing, the 
‘Master’ was located at the Mobile Research Facility. 

In the table below, the column that is titled ‘Size’ signifies the size of the 
data file that was sent from one computer in one network to another computer in the 
opposite network via Microsoft Windows file sharing. The data files consisted of Word 
documents. Power Point presentations, and PDF files. There was no video or voice 
utilized at the time of this testing. The ‘From’ and ‘To’ column show the last digits of 
the computer IP address (I92.I68.x.x). Table II shows the data collected during the 
SecNet testing at 500 meters. 


Run No. 

Media 

Size 

Time 

Throughput 

Packet Loss (%) 

From 

To 

1 

SECNET 11 

1.5 M 

41" 

946K 

12% 

3.4 

1.2 

2 

SECNET 11 

5 M 

ro3" 

1.06M 

10% 

3.4 

1.2 

3 

SECNET 11 

10 M 

3'29" 

1.13M 

14% 

3.4 

1.2 

4 

SECNET 11 

25 M 

4'05" 

1.19M 

24% 

3.4 

1.2 

5 

SECNET 11 

75 M 

11'07" 

1.13M 

17% 

3.4 

1.2 

6 

SECNET 11 

1.5M 

23" 

600K 

9% 

1.2 

3.3 

7 

SECNET 11 

5M 

ri2" 

400K 

14% 

1.2 

3.3 


Table 11. RAW DATA SECNET-11 POINT-TO-POINT 


In addition to the point-to-point testing accomplished with SecNet-I I, data 
was collected on the use of a SecNet access point within a local area network. In this 
setup, an access point with a SecNet card was set up in the Mobile Research Eacility 
network with two laptops wirelessly connected to that access point. The laptops each had 
their own SecNet card inserted. To configure the laptop appropriately with the card’s 
software, the computer had to be in Administrator mode. Einally, the access point was 
wired into the EAN’s switch with CAT-5 cable. Table 12 below shows the data obtained. 
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Media 

Size 

Time 

Throughput 

Packet Loss (%) 

From 

To 

VOiCE 

SECNET 11 

1.5 M 

6" 

1.2M 

0% 

3.102 

3.103 

NO 

SECNET 11 

5 M 

23" 

2.1M 

0% 

3.102 

3.103 

NO 

SECNET 11 

10 M 

lost 

2.1M 


3.103 

3.102 

NO 

SECNET 11 

10M 

53" 

2.94M 

0% 

3.103 

3.102 

NO 

SECNET 11 

75 M 

r36" 

2.3M 

0% 

3.102 

3.103 

NO 

SECNET 11 

10M 

21" 

4.94M 

0% 

3.102 

3.102 

NO 

SECNET 11 

10M 

o 

CO 

3.93M 

0% 

3.7 

3.102 

NO 


Table 12. RAW DATA SECNET-11 IN LAN 


The reason for this testing was that General Dynamic’s personnel were 
interested in knowing how many laptops the access point could handle. Since the 
students did not have the ability to associate a multitude of laptops to the access point, 
they accomplished the goal by transferring large files between computers in order to 
simulate a large volume of throughput in the network. Any size file that was above 
75Mb was unsuccessful in its transfer from one computer to another. 

b. Radio Frequency Module (RFM) 

GDDS provided a REM v3 system during two days of the testing 
evolution, January 6 and 8, 2004. Ceragon Networks is the actual producer of the REM 
product. However, GDDS packages the product in appropriate cases along with a Cisco 
2950 switch for their customers. This case along with the microwave dish is field 
expedient and hardened to withstand a rugged military environment. The antenna sits on 
top of a lightweight telescopic stand, which is separate from the case. A distance of 9 
kilometers can be reached with the one-foot antenna, which was used during the testing 
event, and 13.5 kilometers with the two-foot antenna.29 REM is a point-to-point, line-of- 
sight, OC-3 capable (155 Mbps) microwave product. Eigure 22 shows the REM antenna, 
tripod, and case. 


29 GDDS, “Radio Frequency Module (RFM) v3 Handout”, 2003. 
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Figure 22. GDDS RFM v3 


Next, the frequency band that the RFM product utilizes can be found in 
Table 13 below. Whichever channel is chosen, the transmitting and receiving frequencies 
are slightly separated in order to avoid any interference. 


Channel 

TX Freq (MHz) 

RX Freq (MHz) 

1 

14515 

14935 

2 

14543 

14963 

3 

14571 

14991 

4 

14599 

15019 

5 

14627 

15047 

6 

14655 

15075 

7 

14683 

15103 

8 

14711 

15131 


Table 13. RFM FREQUENCY BANDS 


The first day of testing with REM offered a chance to become familiar 
with the product and work out any problems. On the second day, it was utilized with 
MRV’s Optical Switch (OptiSwitch) that automatically switches over from FSO to RE if 
the ESO signal is lost or degraded. The REM product was tested at 1,000 meters on both 
days. 
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During the first day, some minor problems were eneountered. Sinee the 
RFM equipment was utilizing the Ciseo switch found within the carrying case, the ports 
of the switch were not configured appropriately to match the Local Area Network routers 
and switches. This equipment was configured for speed 100 (100 Mbps) and full duplex. 
The RFM Cisco switch was set on auto-negotiation. Cisco products that are not set on 
the same settings throughout the network will not function properly, which can cause 
degradation in the networks. Thus, initially the authors were seeing low throughput data 
for the RFM gathered from Iperf (see appendix for explanation of Iperf), which can be 
seen in Figure 23 below. Note that Iperf was sending a flood of 64Kb size packets to get 
this throughput data. At this testing evolution, the authors were unable to change the size 
of the packets. In the later experiments, the packet size could be changed. The normal 
throughput capability of the RFM system is OC-3 (155 Mbps) but the router and switch 
ports could only handle 100 Mbps. In addition to the low throughput data, the link was 
very unstable and constantly showing as signal lost in SolarWinds network monitoring 
system (see appendix for full explanation) during the times the RFM Cisco switch was set 
at auto-negotiation. 


Client connecting to 192.168.1.2, TCP port 5001 
TCP window size: 63.0 KByte (default) 


[928] local 192.168.3.4 port 1034 connected with 192.168.1.2 port 5001 


[ ID] Interval 
[928] 0.0- 5.0 sec 
[928] 5.0-10.0 sec 
[928] 10.0-15.0 sec 
[928] 15.0-20.0 sec 
[928] 0.0-20.0 sec 


Transfer 
17.1 MBytes 

17.5 MBytes 
15.0 MBytes 
19.0 MBytes 

68.5 MBytes 


Bandwidth 

27.3 Mbits/sec 
28.0 Mbits/sec 
23.9 Mbits/sec 

30.4 Mbits/sec 

27.4 Mbits/sec 


Figure 23. RFM IPERF DATA BEFORE CONFIGURING SWITCH 


After getting the RFM Cisco switch port that was connected to the existing 
network set to speed 100 and full duplex, the data and link were very consistent and 
stable. SolarWinds showed the link up throughout the rest of the day. The Iperf data 
after the proper configuration settings can be found in Figure 24 below. 
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Client connecting to 192.168.1.2, TCP port 5001 
TCP window size: 63.0 KByte (default) 


[928] local 192.168.3.4 port 1037 connected with 192.168.1.2 port 5001 


[ ID] Interval 
[928] 0.0- 5.0 sec 
[928] 5.0-10.0 sec 
[928] 10.0-15.0 sec 
[928] 15.0-20.0 sec 
[928] 0.0-20.0 sec 


Transfer 

32.7 Mbytes 

32.7 MBytes 

32.8 MBytes 
32.5 MBytes 
131 MBytes 


Bandwidth 

52.2 Mbits/sec 

52.3 Mbits/sec 
52.5 Mbits/sec 
52.0 Mbits/sec 

52.3 Mbits/sec 


Figure 24. RFM IPERF DATA AFTER CONFIGURING SWITCH 


On 8 January, the RFM was utilized with MRV’s OptiSwitch. Prior to 
conducting this testing, more data was collected with SolarWinds on the actual 
throughput of the RFM link while transferring data files, such as Word documents. Power 
Point presentations, and PDF files. As it is reflected in the data table below, the link 
would drop out when attempting to transfer files bigger than 300 Mbytes. However, it 
was again very consistent and stable for this test for files 300M and smaller. The data 
from SolarWinds shows a much lower throughput than Iperf because the SolarWinds data 
was measuring how well files transferred from computer to computer when conducting a 
Microsoft Windows file sharing session. In addition, the files were very inconsistent in 
size and type, while Iperf sends packets that are consistent in size and type. See Table 14 
for the SolarWinds data. 


Run No. 

Media 

Size 

Time 

Throughput 

Packet Loss (%) 

From 

To 

10 

MICROWAVE 

1.5M 

1" 

2.3M 

0% 

3.4 

1.2 

11 

MICROWAVE 

5M 

2" 

7.3M 

0% 

3.4 

1.2 

12 

MICROWAVE 

10M 

2" 

15M 

0% 

3.4 

1.2 

13 

MICROWAVE 

25M 

7" 

36M 

0% 

3.4 

1.2 

14 

MICROWAVE 

75M 

17" 

40M 

0% 

3.4 

1.2 

15 

MICROWAVE 

300M 

r30" 

37M 

0% 

1.2 

3.4 

16 

MICROWAVE 

300M 

r08" 

43M 

0% 

3.4 

1.2 

17 

MICROWAVE 

600M 

DROP 



1.2 

3.4 


Table 14. RFM SOEARWINDS DATA ON 8 JANUARY 


In the ESO-RE switchover test, the REM Cisco Switch was connected to 
MRV’s OptiSwitch via a CAT-5 crossover cable. The reason for the crossover cable was 
that two like devices, switches, were connected to each other. With both MRV’s ESO 
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product and the RFM connected to the OptiSwitch, the transition from one to the other 
was seamless. In order to facilitate the FSO signal being lost, a box was placed in front 
of the FSO link head. There was no packet loss or delay in the transfer of files from 
computer to computer. When the box was taken away from the link head, the FSO 
product picked up the transmission again without any delay or noticeable difference in 
the transition. Again, SolarWinds was used to read the throughput data, and file sharing 
between computers was the method being used to flood the link with data. Table 15 
below shows the data for the FSO-RF test. 


Run No. 

Media 

Size 

Time 

Throughput 

Packet Loss (°/^ 

From 

To 

19 

FSO 

300M 

1'31" 

24MRF,36MFSO 

0% 

3.4 

1.2 

20 

FSO 

150M 

"50 

41 RF, 42 FSO 

0% 

3.4 

1.2 

21 

FSO 

75M 

"27 

6 RF, 30 FSO 

0% 

1.2 

3.4 

22 

FSO 

300M 

200" 

24 RF, 31 FSO 

0% 

1.2 

3.4 

23 

FSO 

600M 

4'24" 

24 RF, 35 FSO 

0% 

1.2 

3.4 


Table 


5. 


FSO-RF SWITCHOVER 


c. fSONA 

After field test #1, the authors were much more familiar with ISONA’s 
product, SONAbeam 155-M. For this testing evolution, the exact same setup for 
ISONA’s equipment was utilized as the previous testing. The SONAbeam 155-M was 
connected to a media converter with a single-mode fiber cable. The media converter was 
outfitted with a SC-fiber connection with RJ-45 out to the network’s router. Attempts 
were initially made to connect lEONA’s product directly from the link heads to the 
network routers with the single-mode cable. The network routers were equipped with a 
Gigabit Network Interface Module to accept a fiber connection. This configuration of the 
SONAbeam 155-M directly to the router was unsuccessful. The reason for this was that 
the single-mode fiber interface on the SONAbeam 155-M was 1310 nanometers. The 
Gigabit Network Interface Module only accepted 850 nanometer signals from the fiber. 
Next, the SONAbeam 155-M was set up on the heavy-duty stands that weighed a total of 
200 pounds each. This provided the SONAbeam 155-M with a stable platform to mount 
the product. Finally, ISONA had a separate Alternating Current (AC) to Direct Current 
(DC) converter. This allowed the link head to be plugged into the power converter with 
DC power, and then the power converter had a regular AC 120V plug that went into the 
available generators. 
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ISONA’s testing was conducted at 1,000 meters down an airfield runway. 
The conditions were ideal with clear skies and sunny weather. Scintillation was much 
more prevalent during this testing event since the link heads were only six feet off the 
ground and the runway was black pavement. This is significant because scintillation can 
cause serious degradation in the laser being sent between link heads. Some testing was 
also done with the SONAbeam 155-M during the nighttime when there was complete 
darkness, when scintillation is much less of an issue. 

Captain Gilbert Garcia and LT A1 Seeman did the setup of the SONAbeam 
155-M equipment. Pablo Bandera, IBONA’s Product Manager, was available to fine- 
tune the alignment of the lasers. A voltmeter was used to determine the strength of the 
signal between the link heads. This established link did not drop once throughout the day 
and proved to be the most stable FSO link during this event. 

Other performance measures were taken during INONA’s allotted time 
slot on the 7 January 2004. Since IBONA’s SONAbeam 155-M product has four 
transmitting lasers and a large distinctive receiving area, data was gathered when 
blocking the transmitting lasers one at a time starting with one, then two, and finally 
blocking three lasers out of the four. In addition, three lasers were blocked along with 
roughly 95% of the receiver area. A picture of this can be found in Figure 25 below. The 
lasers on the edges were being blocked with cardboard taped over them and the receiver 
area was blocked with a pizza box. 
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Figure 25.'" PABLO BANDERA, PSONA, BLOCKS LASERS AND RECEIVER 


The data eollected for the regular testing, blocking lasers, and night testing 
can be found Table 16 below. As can be seen from the data, the link was very stable no 
matter the size of the files being transferred. During the night testing. Voice over Internet 
Protocol was also implemented. There was one phone in each respective network. Each 
phone required about 90 Kbps of throughput, so it had minimal effect on the performance 
of the laser link. The files being transferred were again Word documents. Power Point 
presentations, and PDE files. There was no Iperf data gathered for IBONA during this 
testing event. 
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1 lasers blocked 

2 lasers blocked 

3 lasers blocked 
lasers/receiver blocked 


Run No. 

Media 

Size 

Time 

Throughput 

Packet Loss 

From 

To 

1 

FSO 

1.5 M 

n/a 

2.2M 

0% 

1.2 

3.3 

2 

FSO 

5 M 

2" 

6.2M 

0% 

1.2 

3.3 

3 

FSO 

10 M 

3" 

15M 

0% 

1.2 

3.3 

4 

FSO 

25 M 

5" 

34M 

0% 

1.2 

3.3 

5 

FSO 

75 M 

17" 

39M 

0% 

3.4 

1.2 

6 

FSO 

150 M 

39" 

39M 

0% 

3.4 

1.2 

7 

FSO 

300 M 

ri5" 

34M 

0% 

3.4 

1.2 

8 

FSO 

150M 

28" 

54M 

0% 

1.2 

3.3 

9 

FSO 

300M 

57" 

56M 

0% 

1.2 

3.3 

10 

FSO 

600M 

2'58" 

47M 

0% 

1.2 

3.4 

11 

FSO 

1.2G 

5'20" 

54M 

0% 

1.2 

3.4 

12 

FSO 

300M 

ri3" 

44M 

0% 

1.2 

3.4 

13 

FSO 

300M 

ri5" 

50M 

0% 

1.2 

3.4 

14 

FSO 

300M 

ri5" 

50M 

0% 

12 

3.4 


NO DATA GATHERED, LINK DID NOT DROP 



10 

FSO 

1.5 M 

N/A 






11 

FSO 

5 M 

2" 

7M 

0% 

1.2 

3.4 


12 

FSO 

10 M 

3" 

15M 

0% 

1.2 

3.4 


13 

FSO 

25 M 

5" 

37M 

0% 

1.2 

3.4 


14 

FSO 

75 M 

20" 

31M 

0% 

3.4 

1.2 


15 

FSO 

300M 

r20" 

42M 

0% 

1.2 

3.4 


16 

FSO 

300 M 

r35" 

30M 

0% 

3.4 

1.2 


17 

FSO 

600 M 

3'15" 

44M 

0% 

1.2 

3.4 


18 

FSO 

1.2 GIG 

6'05" 

46M 

0% 

1.2 

3.4 

Table 16. 

FSONA DATA 7 JAh 

JUAY 


d. MRV 

Tim Kcehowski, Director of Federal Sales, Levon Fayson, Technical 
Support Engineering Manager, and Isaac Kim, Director of FSO, from MRV 
Communications supported this testing event. Mr. Fayson was instrumental in setting up 
the Terescope 3000 OC-3 link heads. The distance between both sites was 1,000 meters 
over a black pavement runway, and the weather was ideal with clear skies and a 
temperature in the 70-degree range. 

The Terescope 3000 OC-3 specifications state that it can reach out to 4 
kilometers with a 3 dB loss per one kilometer, which would equate to light haze, and still 
provide 99.999% reliability.30 

MRV also brought along with them their OptiSwitch that automatically 
switches over from FSO to RF when the FSO link is lost. The MRV TereScope product 
supports a patent optional software feature called “Terescope Fusion”. This feature 

30 Isaac Kim, “Terescope Free Space Optics Overview Brief’, 2003. 
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provides auto switch over from the TereScope product to any back up RF system. The 
software in the Terescope communicates with the MRV manufactured OptiSwitch 
product to provide switching between the FSO and backup RF system. The OptiSwitch 
also has unique software to communicate with the Terescope. The RFM product was 
used as the backup RF system during this testing event. Figure 26 below demonstrates 
MRV’s OptiSwitch used during the testing event. 



Figure 26. MRV OPTISWITCH 200 

From the Terescope 3000, there was a multi-mode fiber cable that ran to 
the media converter that MRV brought with them. The media converter had an RJ-45 
connection that went from the converter to the network’s 3745 router. Next, there was a 
AC to DC converter, separate from the link head, which allowed the DC powered link 
head to be plugged into the available AC 120V power source on the generators. 

The Terescope 3000 alignment process was done via a camera located 
within the Terescope. This camera is capable of seeing the laser light from the other link 
head. One can view what the camera is seeing on a display that is separate from the 
actual link head. The video alignment software is built into the TereScope product, and it 
can be remotely viewed by extending the video back to the user in the Operations Center. 
Once the camera sees the laser light from the other link head, one can manually move the 
link head to get the laser light in the center of the cross hairs on the video display. The 
alignment process was relatively simple once viewed on the display screen. See Figure 
27 below to view MRV’s Terescope 3000 and the display screen for the alignment. The 
camera feature can also be viewed on other sources such as laptops and palm pilots by 
taking either a CAT 5 cable or fiber connection out of the Scope to the network 
equipment. In addition to the patent MRV video alignment, MRV is adding tracking and 
auto alignment into their units. 
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Figure 27. MRV TERESCOPE 3000 W/ ALIGNMENT DISPLAY 


Throughput data was collected on the Terescope 3000 via fde sharing on 
Microsoft Windows and packet flooding on Iperf. The data collected was inconsistent, 
with considerable packet loss when transferring large files. In addition, no files larger 
that 300 Mbytes could be transferred between computers on the different networks. 
Table 17 below shows the file sharing data collected utilizing SolarWinds as the 
measuring tool. 
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'nil 1 III 

Media 

Size 

Time 

Throughput 

Packet Loss 

From 

To 


FSO 

1.5 M 

1" 

2.2M 

0% 

3.4 

1.2 


2 

FSO 

5M 

2" 

7.3M 

0% 

3.4 

1.2 


3 

FSO 

10M 

5" 

9M 

0% 

1.2 

3.3 


4 

FSO 

25 M 

7" 

27M 

0% 

3.4 

1.2 


5 

FSO 

75 M 

34" 

25M 

0% 

1.2 

3.3 


6 

FSO 

150 M 

drop 






7 

FSO 

300 M 

r54" 

25M 

15% 

1.2 

3.3 


8 

FSO 

600 M 




1.2 

3.3 


9 

FSO 

1.2 GIG 








10 

FSO 

1.5M 

1" 

2.3M 

7% 

3.4 

1.2 


11 

FSO 

5M 

2" 

7.3M 

0% 

1.2 

3.3 


12 

FSO 

10M 

7" 

11M 

0% 

1.2 

3.3 


13 

FSO 

25 M 

20" 

10M 

0% 

1.2 

3.3 


14 

FSO 

75 M 

31" 

23M 

20% 

3.4 

1.2 


15 

FSO 

150 M 

drop 






16 

FSO 

300 M 

4'00" 

16M 

0-4% 

1.2 

3.3 


17 

FSO 

600 M 







18 

FSO 

1.2 GIG 






Tab 

leI7. MRV DATA 8 JA 

NUARY 


The throughput readings were low for a system that is eapable of OC-3 
rates (limited to 100 Mbps due to the network ports). After getting these readings, 
eonsiderable time was spent on troubleshooting the problem. It was believed that the 
settings on the media converter were incorrect, so calls were made back to MRV’s office. 
After establishing what was believed to be the right settings, the authors set up laptops off 
of the link heads through the media converters on both sides and used Iperf to gather the 
throughput data. This data can be found in Figure 28 below. 


Client connecting to 192.168.64.221, TCP port 5001 
TCP window size: 63.0 KByte (default) 


[928] local 192.168.64.220 port 1083 connected with 192.168.64.221 port 5001 


[ ID] Interval 
[928] 0.0- 5.0 sec 
[928] 5.0-10.0 sec 
[928] 10.0-15.0 sec 
[928] 15.0-20.0 sec 
[928] 0.0-20.0 sec 


Transfer 
33.0 MBytes 

32.9 MBytes 

32.9 MBytes 

32.9 MBytes 
132 MBytes 


Bandwidth 

52.7 Mbits/sec 

52.6 Mbits/sec 

52.7 Mbits/sec 

52.6 Mbits/sec 

52.7 Mbits/sec 


Figure 28. MRV IPERF DATA 8 JANUARY 
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While this data shows a big improvement from the previous experiment 
with SolarWinds, it was still low for a connection between computers. The established 
networks were not involved, which usually slows the throughput down at least 10%. 
When MRV went back to their labs after the testing event, they determined that the media 
converters were not set properly, as they attained throughput near 100 Mbps in the labs. 

The FSO-RF switchover with the OptiSwitch was a huge success. Both 
the Terescope 3000 and the RFM were connected to the OptiSwitch with CAT-5 cable; 
and the FSO link was going through the media converter. The Terescope Fusion in 
conjunction with the OptiSwitch was set to have the FSO link as the priority link, so that 
was the link that would be used unless the FSO link was lost. This type of setup proves 
beneficial for situations when the weather is unpredictable. If fog rolls in and the link is 
at 1,000 meters, then the OptiSwitch will eventually start to sense the power level of the 
link being insufficient to get to the other side. At this point, the RF link would take over. 
For this testing event, since the weather was ideal, a box was placed in front of the 
Terescope to drop the FSO link and demonstrate how the RF picks up the connectivity. 
After a short while, the box was taken away from the FSO link and the Terescope came 
back up as the priority link. The data collected during this testing was from SolarWinds 
and it can be found in Table 18 below. 


Run No. 

Media 

Size 

Time 

Throughput 

Packet Loss (%) 

From 

To 

19 

FSO 

300M 

r3i" 

24M RF, 36M FSO 

0% 

3.4 

1.2 

20 

FSO 

150M 

"50 

41 RF, 42 FSO 

0% 

3.4 

1.2 

21 

FSO 

75M 

"27 

6 RF, 30 FSO 

0% 

1.2 

3.4 

22 

FSO 

300M 

2'00" 

24 RF, 31 FSO 

0% 

1.2 

3.4 

23 

FSO 

600M 

4'24" 

24 RF, 35 FSO 

0% 

1.2 

3.4 


Table 18. MRV AND RFM W/ MRV’S OPTISWITCH 


Large file transfers were used to extend the time it took to accomplish the 
transfer. This assisted the authors in viewing the capability of the OptiSwitch and for 
them to see if the transfer was interrupted or if any packet loss occurred. Neither of these 
situations took place. 

e. Lightpointe 

Lightpointe’s team consisted of Jim McGowan, Sales Director, and Albert 
Borquez, Network Engineer. They brought their FlightStrata Gigabit Fly Away Package 
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with them, which consisted of one ruggedized travel case per link head and accessories. 
This whole case weighs about 70 pounds and is easily rolled around via a handle and 
wheels attached to the case. The FlightStrata transmits four redundant beams of light that 
overlap and adjust via Multi-Beam Array Tracking (MBAT) technology. The system 
also has an Automatic Power Control feature that allows the link head to automatically 
adjust its power output based on the situation with weather or distance.31 Finally, the li nk 
head sits on top of a lightweight, three-foot, telescopic tripod that fits into the traveling 
case. 

The setup was fast and simple. The FlightStrata proved to be the easiest to 
set up out of all FSO products. After setting up the stand, the link head was attached to 
the top with four screws. There was also a separate box for the AC to DC power 
conversion to facilitate an AC 120V plug-in to the generators. Furthermore, the 
alignment was simple but not the most advanced feature. The scope to find the other end 
was built-in to the link head. After getting close to the alignment, the Light Emitting 
Diode (LED) indicator on the back of the link head was utilized as the link head was 
manually adjusted to try and obtain the strongest signal. This was signified by the 
amount of LED bars that lit up. It was best to do this one side at a time and to have voice 
contact with the other side in order to get feedback from them as to what their LED bars 
were indicating. 

During this testing evolution, Lightpointe utilized multi-mode cable from 
their ElightStrata directly to the network’s Gigabit Interace Modules on the Cisco 3745 
routers. This allowed them to avoid using the media converters. Lightpointe was the 
only ESO company able to connect their link head directly to the router with fiber 
throughout the week. The data results were very stable and the throughput was greater 
than other companies mostly due to the direct fiber connection to the router from the 
ElightStrata. Table 19 below shows the results obtained from SolarWinds throughout the 
day while doing file transfers, file transfers and VoIP, and file transfers and VoIP while 
blocking lasers. 


31 http://www.lightpoiiite.cotn/index.cftn/fuseaction/products.flightstrata (April 2004). 
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Run No. 

Media 

Size 

Time 

Throughput 

Packet Loss 

From 

To 

1 

FSO 

1.5 M 

1" 

2.3M 

0% 

3.4 

1.2 


2 

FSO 

5 M 

1" 

7.3M 

0% 

3.4 

1.2 

3 

FSO 

10 M 

1" 

15M 

0% 

1.2 

3.3 

4 

FSO 

25 M 

5" 

31M 

0% 

3.4 

1.2 

5 

FSO 

75 M 

15" 

53M 

0% 

1.2 

3.3 

6 

FSO 

150 M 

27" 

53M 

0% 

3.4 

1.2 

7 

FSO 

300 M 

r03" 

56M 

0% 

1.2 

3.3 

8 

FSO 

600 M 

NOT ATTEMPTED 



9 

FSO 

1.2 GIG 

5'00" 

50M 

0% 

3.4 

1.2 


1 LASER BLOCKED 

2 LASERS BLOCKED 

3 LASERS BLOCKED 

10 

FSO 

1.5 M 

1" 

2.3M 

0% 

3.4 

1.2 

11 

FSO 

5 M 

1" 

7.4M 

0% 

3.4 

1.2 

12 

FSO 

10 M 

r 

15M 

0% 

3.4 

1.2 

13 

FSO 

25 M 

4' 

15M 

0% 

3.4 

1.2 

14 

FSO 

75 M 

15" 

47M 

0% 

3.4 

1.2 

15 

FSO 

150 M 

32" 

54M 

0% 

1.2 

3.4 

16 

FSO 

300 M 

54" 

48M 

0% 

3.4 

1.2 

17 

FSO 

600 M 

2'20" 

53M 

0% 

3.4 

1.2 

18 

FSO 

1.2 GIG 

5'02" 

55M 

0% 

3.4 

1.2 

19 

FSO 

300M 

56" 

61M 

0% 

3.4 

1.2 

20 

FSO 

300M 

52" 

54M 

0% 

3.4 

1.2 

21 

FSO 

300M 

49" 

55M 

0% 

3.4 

1.2 

Table 

9. LIGHTPOE 

"^TE DAI 

^A 9 JAh 

lUARY 


As one can see, the link was able to handle any size file transfer without 
packet loss, and a subset of the lasers being blocked had no negative effect on the li nk . 
Below in Figure 29 are the results from Iperf when 64 Kbyte size packets were flooding 
the li nk . 



Client connecting to 

192.168.1.2, TCP port 5001 

TCP window size: 63.0 KByte (default) 

[928] local 192.168.3.4 port 1148 connected with 192.168.1.2 port 5001 

[ ID] Interval 

Transfer 

Bandwidth 

[928] 0.0- 5.0 sec 

50.1 MBytes 

80.1 Mbits/sec 

[928] 5.0-10.0 sec 

50.0 MBytes 

80.1 Mbits/sec 

[928] 10.0-15.0 sec 

50.4 MBytes 

80.7 Mbits/sec 

[928] 15.0-20.0 sec 

50.4 MBytes 

80.5 Mbits/sec 

[928] 0.0-20.0 sec 

201 MBytes 

80.3 Mbits/sec 


Figure 29. LIGHTPOINTE IPERF DATA 
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Lightpointe’s Iperf data was the strongest throughout the entire week. The 
link did tend to drop a couple of times for a few seconds possibly due to cars driving 
down the runway in the line of the laser link, dust being kicked up by the cars, or 
scintillation from the sun hitting the black runway. In addition, the sporadic link drop 
could have been due to Lightpointe’s tripod stand being only 3 feet off the ground, the 
lowest out of all the companies. 

f. Ensemble 

Ensemble Communications supported this evolution with Jeff Nightingale, 
Sales Director, Corey Koberg, Engineer, and Jerry Shirey, Eield Technician. They 
brought equipment that utilizes 802.16 technology. 802.16 is made for Wide Area 
Networks (WAN), much like 802.1 lx is utilized in Eocal Area Networks. In the 
commercial sector, 802.16 is used for backhaul broadband wireless connectivity for many 
service providers. IEEE has already developed standards for 802.16a (2-11 GHz) and 
802.16c (10-66 GHz). The reason this technology is made for Wide Area Networks 
(WAN) is because of its point-to-multipoint features. The equipment comes in the 
following parts: hub station, multiplexer, and antenna. At the hub station. Ensemble can 
use 60, 90, and 180-degree antennas to provide 360-degree coverage to the remote 
stations. The remote stations have the multiplexer with their own appropriate type of 
sector antenna. Ensemble’s products operate on the Asynchronous Transfer Mode 
(ATM) protocol.32 A new product line is being developed to support Internet Protocol. 

Since Ensemble’s system was ATM based, the authors attained a Single 
port ATM OC-3 Single-mode Intermediate Reach NM card for the Mobile Research 
Eacility’s 3745 router. The 16200 Hub Station was connected to the port on the card with 
a single-mode fiber cable. The 320 Multiplexer was on the other end, connected to the 
3745 router with CAT-5 cable. A Eiberless 282 Series Outdoor Mounted Unit (ODU) 
was utilized for the antenna. It operates in the 27.50 to 28.55 GHz range. Other ODU’s 
can be utilized which can operate in the 24 to 40 GHz range.33 A special frequency 
request was sent to the Navy/Marine Corps Spectrum Center to get temporary 

32 http://www.ensemble.com/product/index.asp (April 2004). 

33 Ensemble Communications, “Fiberless Integrated Antenna and Radio Outdoor Unit”, December 
2003. 
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authorization to utilize the frequency band in order to operate the 282 Series ODU. As 
mentioned earlier, the antennas mostly function in a point-to-multipoint environment. 
However, in this testing only point-to-point was attempted utilizing the 90-degree sector 
antennas at both sites. 

To further explain Ensemble’s product capabilities, the ODUs 
communicate between the hub station and multiplexer sites using the company’s 
revolutionary, patented Adaptix broadband airlink technology to maximize system 
capacity and efficiency in real time. Physical layer Adaptix features include both 
Adaptive Time Division Duplexing (TDD) and Adaptive Modulation. Adaptive TDD 
uses a single RE channel for both upstream and downstream communications and permits 
the system to adapt in real-time to the exact asymmetry of subscriber traffic burst by 
burst. Adaptive TDD also fits easily into the many different kinds of spectrum 
allocations worldwide including block, paired, and split band frequency licenses. The 
ODU’s excellent phase noise characteristics enable the system to support not only QPSK 
and 16QAM, but also 64QAM operation burst by burst.34 

Ensemble’s link was set up to attain a maximum throughput of 66 Mbps 
with that being split between the two-way traffic. Thus, if both sites were sending data at 
the same time, then each flow of traffic would be allotted 33 Mbps of throughput. Next, 
the setup of the equipment required detailed configuration of the router at the hub 
station’s site. This ended up taking approximately six hours of work with several 
individuals working on the configuration. The ATM configuration proved to be much 
more complex than Internet Protocol, which was used by all the other companies. 

Data was collected in SolarWinds for the throughput capabilities of 
Ensemble’s equipment. Again, data file transfers were conducted between laptops on the 
two networks, and VoIP was being utilized during these transfers. See Table 20 below 
for this data. 


34 Ensemble Communieations, “Fiberless Integrated Antenna and Radio Outdoor Unit”, Deeember 
2003. 
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Run No. 

Media 

Size 

Time 

Throughput 

Packet Loss (%) 

From 

To 

1 

802.16 

1.5 M 

1" 

2.3M 

0% 

3.4 

1.2 

2 

802.16 

5 M 

13" 

4.42M 

0% 

1.2 

3.4 

3 

802.16 

10 M 

25" 

5.4M 

0% 

1.2 

3.4 

4 

802.16 

25 M 

50" 

5.0M 

0% 

1.2 

3.4 

5 

802.16 

75 M 

r07" 

12M 

9% 

3.4 

1.2 

6 

802.16 

150 M 

5'15" 

5M 

0% 

1.2 

3.4 

7 

802.16 

25M 

"22 

11M 

0% 

3.4 

1.2 

8 

802.16 

75M 

roo" 

11M 

0% 

3.4 

1.2 

9 

802.16 

150M 

3'05" 

11M 

0% 

3.4 

1.2 


Tab 


e 20. 


ENSEMBLE 802.16 DATA 8 JANUARY 


After analyzing the data, it was evident that the yielded throughput data 
was low compared to the other technologies. However, since the channel capacity was 
about 33 Mbps one way, this data compares similarly with the other companies observed 
throughput as a proportion of maximum channel capacity. The other companies were 
attaining 40-60% capability of the link while connected to the LANs and also conducting 
Microsoft Windows file sharing. 


Below in Eigure 30 is the throughput data from Ip erf that was obtained by 


flooding Ensemble’s link with 64 Kbyte size packets. 


Client connecting to 192.168.1.2, TCP port 5001 
TCP window size: 63.0 KByte (default) 


[928] local 192.168.3.4 port 1033 connected with 192.168.1.2 port 5001 


[ ID] Interval 
[928] 0.0- 5.0 sec 
[928] 5.0-10.0 sec 
[928] 10.0-15.0 sec 
[928] 15.0-20.0 sec 
[928] 0.0-20.0 sec 


Transfer 

6.3 MBytes 

6.4 MBytes 

6.4 MBytes 

6.4 MBytes 
25.5 MBytes 


Bandwidth 

10.1 Mbits/sec 

10.2 Mbits/sec 

10.2 Mbits/sec 

10.3 Mbits/sec 
10.2 Mbits/sec 


Figure 30. ENSEMBLE IPERF DATA 8 JANUARY 


Note: Ensemble Communications decided to shut down the company in 

April 2004. 

g. Digital Switch Unit (DSU) 

One of the main reasons for conducting an experiment in Scottsdale, AZ 
was to work with the UOC team and their equipment. The Digital Switch Unit (DSU) is 
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the heart of how the UOC will operate in the future. This system provides the user 
aeeess, from a laptop or an operator access unit, to all available voice circuits (radio and 
telephone). The connectivity is obtained by connecting the laptop to one of the 
Jackboxes available at each operator station. Control of the communication devices is 
through a Graphical User Interface (GUI) software application resident on the laptop. 
This provides the button to access the Public Switched Telephone System (PSTN), Plain 
Old Telephone System (POTS) and any radios connected to the Communications net.35 
A VoIP intercom system will also be available to use through the DSU. From the laptop, 
the user has the ability to call anyone in the LAN through the GUI. Additionally, this 
arrangement can be used in the COC to Antenna Hill scenario. 

During this testing evolution, the UOC team first brought out their 
Engineering Development Model DSUs to set up within the respective LANs. After 
some trouble with the configuration the first few days, a decision was made to use the 
Low Rate Initial Production DSUs. On Lriday, January 9, the DSUs were connected to 
the LANs with success. 

The setup of the UOC equipment at the Mobile Research Lacility was 
relatively straightforward. The General Dynamics’ Panasonic Toughbooks were 
connected to the LAN Cisco 3550 switch with CAT-5 cable, and the DSU was also 
connected to the LAN Cisco 3550 switch with CAT-5 cable. This was the same setup for 
the other LAN. The link between the two LANs was Lightpointe’s LSO product, 
LlightStrata-G. On the Toughbooks, there was a GUI available to make VoIP calls 
within either LAN. Utilizing the GUI was a success while communicating across the 
network. The quality of the voice transmissions was excellent and there seemed to be no 
delay. 

The disadvantage of this setup was that the two LANs needed to be on the 
same subnet in order for the DSUs to work effectively. This would be sufficient for a 
COC to Antenna Hill scenario, but if attempting to go from COC to COC this would not 
be a realistic option. Lurther research needs to be done into the Internet Protocol 
addressing scheme with the DSUs. 

35 General Dynamics Decision Systems, “UOC Summary Brief’, 2003. 
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h. Voice Over Internet Protocol (VoIP) 

The authors were able to expand upon their thesis research objectives after 
conferring with other students at the Naval Postgraduate School. This research team 
recognized the various potential benefits of bringing in another student that was doing 
VoIP thesis research. LT Manny Cordero was able to easily merge his thesis objectives 
into the author’s testing events. Since the authors were already planning on setting up 
two LANs to test the different transformational technologies, LT Cordero implemented 
his equipment right into the network. Consequently, LT Cordero was able to see how 
VoIP reacted to the different types of throughput capabilities. The authors were able to 
attain a Cisco Call Manager Server, MCS-7825H-2.2 EWl model, and two 7960G VoIP 
telephones from Cisco for the VoIP testing. The 7960G phone can be seen in Figure 31 
below. 



Figure 31. CISCO VOIP 7960G PHONF 


Once at GDDS, Don Fesmeister, the coordinator of the testing event at 
General Dynamics, provided additional Cisco 7940G and 7960G telephones due to the 
two telephones originally attained having different protocol loads. Tony Cordaro from 
Ocean Systems Engineering Corporation (OSEC) was also instrumental in providing 
support to FT Cordero in getting the VoIP functional. Mr. Cordaro normally assists the 
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UOC team with their network setup, so Don Lesmeister invited him to Seottsdale to 
observe this testing evolution. 


As mentioned earlier, a mixture of Cisco 7940G and 7960G IP telephones 
were used to provide voice service throughout the network. The phones took a simple 
CAT-5 cable connection, while the other end was connected to the LAN Cisco 3550 
switch. The Call Manager server was always located in the MRF. The phones 
throughout the two LANs first talked to the server before making a call to another phone 
within the network. The server was connected to the MRF Cisco 3550 switch via CAT-5 
cable. Each phone and server was assigned its own unique IP address. 

Once the phones established connectivity, the authors were able to 
measure the throughput of a VoIP phone call. SolarWinds was able to monitor the LAN 
routers, so it measured throughput during a phone call. A call between two phones took 
up about 90 Kbps of throughput. During this testing event, the students were unable to 
establish more than one phone within the LANs due to equipment limitations. With the 
technologies being tested, the available throughput far exceeded the requirement of the 
phone call so the Quality of Service was excellent. The VoIP protocol employed was 
Cisco’s Call Manager Skinny Client Control Protocol (SCCP). SCCP is a Cisco 
proprietary protocol used between Cisco Call Manager and Cisco VoIP phones (7940G 
and 7960G IP phones). Other vendors also support this protocol. The Cisco IP Phones 
7960G and 7940G are also capable of supporting other protocols such as Session Initiated 
Protocol (SIP) and Media Gateway Control Protocol (MGCP). 

L Crypto (KG-235 In-Line Network Encryptor (INE)) 

GDDS provided two KG-235 Sectera In-Line Network Encryptors (INE) 
and a trained operator from the company, Russ Harris, to set them up. GDDS is actually 
the manufacturer of this product as well. The intent of using these devices was to secure 
the link between the two EANs and to measure if there was any noticeable difference in 
the throughput with the encryption applied. 

The Sectera INE is specifically designed to support IP/Ethemet operating 
over standard commercial networks that require U.S. Government Type 1 security, but it 
is also used in the military environment. The Sectera INE protects all levels of data, from 
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Government Classified to TS/SCI. It provides confidentiality, data integrity, peer 
identification, authentication and mandatory/discretionary access control services. The 
Sectera INE is software configured, using the new Sectera INE Configuration Manager 
and is keyed using material supplied by the U.S. Government’s Electronic Key 
Management System (EKMS), for Type 1 products.36 The Communications Interfaces 
on the KG-235 are two RJ-45 10/100 Base T and two DB-9 Serial Ports. The INE can 
support up to 20 Mbps of aggregrate data throughput37 with further planned upgrades 
making that number even higher. 

The INEs were inserted between the technology link and the LAN Cisco 
3550 switch on both LANs. To make the KG-235s work properly within the network, 
they had to replace the LAN Cisco 3745 routers. The KG-235s actually function as a 
router, but when assigning the IP addresses to the two KG-235s they needed to be on the 
same subnet in order for the two networks to see each other. Finally, one of the two 
Ethernet ports on the KG-235s was used to go to the link equipment with CAT-5 cable 
and the other one went to the LAN Cisco switch, also with CAT-5 cable. The laptops 
were also connected to the switch, and they needed to have an IP address of the same 
subnet as the KG-235s. 

Due to some network configuration problems with the KG-235s and one 
of them constantly dropping its fill, the authors were unable to attain any data with the 
KG-235S. 

2, Beyond Line-of-Sight (BLOS) 

Since this testing evolution at GDDS was still at the beginning stages of the 
author’s testing phase, they had not yet interacted with any commercial vendors that 
produced BLOS technology. Later field tests, #3 and #4, demonstrated an Orthogonal 
Frequency Division Multiplexing (OFDM) technology that was able to do terrestrial 
BLOS. Refer to those testing evolutions for the results. 

3, Over-the-Horizon (OTH) 

With this being the first major testing event planned, OTH capable technologies 
had not yet been researched thoroughly. However, GDDS did offer their services in this 

36 http://www.gdc4s.coi'n/Products/sectera.htm (April 2004). 

37 littp://webhome.idirect.cotn/~iproc/crvpto/kg235.html (April 2004). 
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area to at least demonstrate an OTH capability between the two LANs. They worked 
with Dr. Glenn Abousleman from Arizona State University 
( glen.abousleman@gdds.com) in order to utilize the existing Iridium satellite architecture 
to its fullest capabilities. Dr. Abousleman’s work has focused on utilizing a compression 
algorithm over this limited throughput mode of transmission. The following paragraphs 
further explain this capability and how it is encrypted with General Dynamics’ INE. 

a. Iridium Inverse Multiplexer (IMUX) 

A single Iridium channel can only transfer data at 2.4 kbps (not sufficient 
for image and video transmission). Reachback IMUX combines four 2.4 Kbps Iridium 
channels to increase overall bandwidth to 9.6 Kbps.38 The four L-Band transreceivers 
actually feed into an IMUX box that can be seen in the Figure 32 below. 








i' * • 


■ ^ 1 : 



- ■ * 


Figure 32. IMUX39 


There are three modes of operation for the IMUX; Data, Video, and 
Voice transmission mode. The data mode ensures data is not altered during transmission 
(data files, critical imagery, etc.). The video transmission mode can do real-time video 
transmission using custom video compression software (used when loss of video quality 
can be tolerated). Finally, in Voice mode each Iridium channel can be used as a satellite 

telephone.40 

The compression algorithm that Dr. Abousleman developed can 
significantly reduce the size of pictures and video to transmit over the limited throughput 
Iridium links. Through this compression, the user can actually select what parts of a 
picture or video to compress, such as background around the main area of interest, and 
what parts to not apply the compression to, such as a target of interest. After 

38 Dr. Glen Abousleman, “Iridium Inverse Multiplexer (IMUX) Brief’, October 2003. 

39 Dr. Glen Abousleman, “Iridium Inverse Multiplexer (IMUX) Brief’, October 2003. 

40 Dr. Glen Abousleman, “Iridium Inverse Multiplexer (IMUX) Brief’, October 2003. 
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compressing, Dr. Abousleman demonstrated to the authors in a prior visit that the 
transmission takes only seconds to go from one computer, through the satellite links, and 
down to another computer. 

During this testing evolution, problems occurred with the one of the 
IMUX ports that feeds into the Iridium transceiver and one of the KG-235s kept dropping 
its fill. Thus, no data was collected with the Iridium link. Refer to Field Test #3 at 
Raytheon to read about the success of this experiment. 

b. Crypto (KG-235INE) 

General Dynamics’ KG-235 INE was explained in detail above. The KG- 
235 is needed to encrypt and decrypt the Iridium satellite link. The KG-235 was 
programmed with IP addresses exactly the same as mentioned above for the LAN to LAN 
communication. Ligure 33 demonstrates the setup that was planned for this testing 
evolution with the IMUX. The only difference between the actual setup and the picture 
was that the Cisco 3550 switch was between the clients and INE. This type of setup was 
successful at Lield Test #3 at Raytheon. See the next section for this information. 


Iridium Inverse Multiplexer 


OTM COC Network 


USS Coronado Network 


Client 1 
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Figure 33. IMUX WITH INF INSERTED41 


In summary, this testing evolution at General Dynamics in Scottsdale, AZ 
proved to be a significant learning experience for the authors as several companies 
presented their products for demonstration; and they connected to existing LANs that 
were put together by the students. The technologies evaluated were 802.11b over 
SecNet-11, Microwave, FSO, 802.16, and Iridium. In addition, DSUs and VoIP were 
inserted with success. Finally, the Iridium links with IMUX and the KG-235s did not 
meet expectations. However, a great deal of information was obtained and later used in 
order to accomplish the various goals in the next field test at Raytheon. 

C. FIELD TEST #3 (RAYTHEON) 

Four students (Captain Garcia, Captain Joseforsky, Lieutenant Seeman, and 
Lieutenant Cordero) from the Naval Postgraduate School conducted the third field test for 
Marine Corps Systems Command. On February 2-6, the students, along with Raytheon 
and several vendors, participated in communications testing for the Common Aviation 
Command and Control System (CAC2S), a product being built by Raytheon. The testing 
compared current state-of-the-art commercial wireless technologies in the following 
areas: operational ease of use, power and environmental considerations, and 
communication bandwidth. Each technology was evaluated for CAC2S node to CAC2S 
node and for sub-system intra-nodal connectivity. In particular, the students evaluated 
sub-system connectivity from the Processing and Display Subsystem (PDS) to the 
Communications Subsystem (CS) and sub-system connectivity from the PDS to the 
Sensor and Data Subsystem (SDS). The ultimate goal for field test three was to 
determine which technologies would increase throughput on the battlefield at a distance 
greater than six kilometers. The following connectivity diagram was utilized with each 
technology providing the connectivity between the two separate LANs (Figure 34). 


41 Dr. Glen Abousleman, “Iridium Inverse Multiplexer (IMUX) Brief’, October 2003. 
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Figure 34. RAYTHEON CONNECTIVITY DIAGRAM 


The following state-of-the-art wireless technologies were tested; Free Space 
Optics, 802.11b (over SecNet-11), 802.16, Orthogonal Frequency Division Multiplexing 
(OFDM), and Microwave Link. Voice over Internet Protocol (VoIP) was implemented in 
the local area networks to test which technologies handle VoIP best. Finally, the students 
demonstrated a BLOS/OTH capability provided by combining Iridium satellite channels. 
This technology is used in the Marine Corps Warfighting Lab’s Expeditionary Tactical 
Communications System. Over the Iridium link, the Iridium Inverse Multiplexer 
(IMUX) and Compression Algorithm, being developed by Dr. Glen Abousleman, was 
utilized. The figure below is a picture of some of the wireless technologies examined at 
Raytheon testing, the products are (from left to right) the Iridium antenna for the IMUX, 
REM, MRV’s Terescope 5000, and the parabolic antenna for 802.11b over SecNet-11 
(Eigure 35). 
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Figure 35. REMOTE SITE WIRELESS TECHNOLOGIES AT RAYTHEON 


One of the lessons learned from the General Dynamics testing was to use an 
industry standard method in order to measure throughput over the link being tested. The 
industry standard measurement used was SmartBits by Spirent Communications. The 
SmartBits analysis system is the industry standard for high port density testing.42 
According to the Spirent web site, “SmartBits enables you to test, simulate, analyze, 
troubleshoot, develop, and certify network infrastructure.”43 Prior to actual testing at 
Raytheon, the students were able to get a few days of hands-on SmartBits training. The 
capabilities and analysis results were explained and demonstrated (one time) by Spirent 
personnel. The SmartBits system consisted of two chassis that simulated data, voice, and 
video among several users. With this new tool in-hand, the students were ready to 
conduct some testing at Raytheon. 

The following paragraphs will explain each technology by either LOS, BEOS, or 
OTH chronologically. 

1, Line-of-Sight (LOS) 
a. Lightpointe 


42 http://www.spirentcom.com/analysis/product_line.cfm?wt=2&az-c=pl&PL=33 

43 http://www.spirentcom.com/analysis/product_line.cfm?wt=2&az-c=pl&PL=33 
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Lightpointe was the first company tested because they were local and they 
were available to assist in the baseline testing. The personnel from Lightpointe that 
assisted in this field test were Jim McGowen, Director of Sales; and Albert Borquez, 
Senior Network Engineer. The product Lightpointe brought was the FlightStrata-155M. 
The baseline testing was conducted to ensure that the local area networks were operating 
correctly and to ensure the logistical items (tent, remote power, power on the roof of 
Raytheon, etc...) were in place. Many factors, including weather and distance, initially 
challenged this testing evolution. The testing conducted on the first day, 2 February, was 
limited. The table below represents two SolarWinds raw data points which were taken 
late into the night (Table 21). 



Table 21. FSO BASELINE AT RAYTHEON 


In addition to the data monitored by SolarWinds, raw data points were 
taken using Iperf Iperf is a bandwidth measuring tool used to measure end-to-end 
bandwidth by using Transport Control Protocol (TCP) streams.44 The raw data below 
represents some Iperf measurements taken on February 2: 


Server listening on TCP port 5001 
TCP window size; 8.0 KByte (default) 


[108] local 192.168.1.2 
[ ID] Interval 
[108] 0.0-20.0 sec 
[928] 15.0-20.2 sec 
[928] 0.0-21.1 sec 


port 5001 connected with 192.168.3.3 port 1054 

Transfer Bandwidth 

89.7 MBytes 35.8 Mbits/sec 

864 KBytes 1.3 Mbits/sec 

3.5 Mbytes 1.3 Mbits/sec 


44 Ajay Tirumala, Les Cottrell, Tom Dunigan: “Measuring end-to-end bandwidth using Iperf using 
Web 100” *under Iperf folder 
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Looking at the throughput summary data provided by SmartBits (Table 
22, below), it is clear to see the frame loss. The table shows the frame size measured in 
Mbytes, the throughput percentage max load shows the amount of data being processed 
across the link (measured in Mbytes), and the frame loss shows the percentage of packets 
lost in transition between the two chassis. The frame loss measured in this run resulted 
from operating in the rain and in the dark over a large distance. This testing was 
conducted around 2000 hours under rainy conditions. 


FrameSize 

128 

192 

256 

320 

384 

448 

512 

576 

Throughput (% max load) 

10 

10 

10 

10 

10 

10 

10 

10 

Frame Loss (%) 

0.07 

1.33 

0.86 

0 

29.6 

0 

0 

0 

FrameSize 

640 

704 

768 

832 

896 

960 

1024 

1088 

Throughput (% max load) 

10 

10 

10 

10 

20 

10 

20 

10 

Frame Loss (%) 

1.93 

0 

21.2 

4.01 

0 

8.79 

0 

5.88 

FrameSize 

1152 

1216 

1280 

1344 

1408 

1472 


Throughput (% max load) 

10 

10 

20 

10 

10 

10 

Frame Loss (%) 

6.45 

0 

0 

16.6 

0 

0 


Table 22. SMARTBITS RAYTHEON BASELINE TESTING 


The figure below is a product of SmartBits. The figure gives a graphical 
representation of throughput versus frame loss (Eigure 35). 
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Figure 36. SMARTBITS RAYTHEON BASELINE GRAPHICS 

On 3 Eebruary, connectivity between the two sites was again established 
with Lightpointe’s product. The weather was hazy with light rain. The SolarWinds data 
taken was a measure of data fdes (Power Point, Word documents, Excel, and Adobe 
documents) being transferred from one LAN to another LAN. The following data was 
obtained using SolarWinds (Table 23). 
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Run No, 

Media 

Size 

Time 

Throughput 

Loss (%) 

VOICE 

VIDEO 

I 

ESO 

1.5 M 

I" 

2.2M 

0 

NO 

NO 

2 

ESO 

5 M 

7" 

7M 

0 

NO 

NO 

3 

ESO 

lOM 

2 " 

I4M 

0 

NO 

NO 

4 

ESO 

Iperf 


40M 

0 

NO 

NO 

5 

ESO 

75 M 

15" 

35M 

0 

NO 

NO 

6 

ESO 

150 M 

42" 

38M 

0 

NO 

NO 

7 

ESO 

300 M 

r24" 

36M 

0 

NO 

NO 

8 

ESO 

600 M 

2'30" 

38M 

0 

NO 

NO 

9 

ESO 

1.2 GIG 

5'30" 

37M 

0 

NO 

NO 

Table 23. 

LIGHTPO 

INTE AT RAYTHEON 


The following Iperf data points were taken immediately following the 
SolarWinds data: 


Client eonneeting to 192.168.1.2, TCP port 5001 
TCP window size: 63.0 KByte (default) 


[928] local 192.168.3.3 
[ ID] Interval 
[928] 0.0- 5.0 sec 
[928] 5.0-10.0 sec 
[928] 10.0-15.0 sec 
[928] 15.0-20.0 sec 
[928] 0.0-20.0 sec 


port 1054 connected with 192.168. 


Transfer 
22.8 MBytes 
22.8 MBytes 

21.5 MBytes 

22.6 MBytes 

89.7 MBytes 


Bandwidth 
36.5 Mbits/sec 
36.5 Mbits/sec 
34.3 Mbits/sec 
36.1 Mbits/sec 
35.8 Mbits/sec. 


1 


.2 port 5001 


The data below describes the load, throughput. 


packets sent, packets 


received, packets lost, and the percent of lost packets. A throughput summary of the 


detailed data produced by SmartBits is as follows (Table 24). 


Total 

10 

10 

16200 

16198 

2 

0.01235 

Data Group 

N/A 

10 

16200 

16198 

2 

0.01235 

Total 

20 

20 

32500 

32500 

0 

0 

Data Group 

N/A 

20 

32500 

32500 

0 

0 

Total 

30 

20 

48700 

35389 

13311 

27.3327 

Data Group 

N/A 

20 

48700 

35389 

13311 

27.3327 


Table 24. LIGHTPOINTE’S SMARTBITS DATA AT RAYTHEON 
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An example of a portion of a detailed data run for Lightpointe is 
demonstrated in Table 25 below. This table demonstrates how data is simulated across 
the network. One port on Data One sends data to fifty different ports on Data Two. In 
return a port on Data Two sends data to fifty ports on Data One. The example in Table 25 
shows a transfer of data. This system has the capability to simulate data, voice, and video 
as well. 


Total 


10 

10 

16200 

16198 

2 

0.01235 

Data Group 


N/A 

10 

16200 

16198 

2 

0.01235 

Data l:l-l->2:l-l-0 

1518 

0.2 

10 

162 

162 

0 

0 

Data 1:1-1->2:1-1-1 

1518 

0.2 

10 

162 

162 

0 

0 

Data l:l-l->2:l-l-2 

1518 

0.2 

10 

162 

162 

0 

0 

Data l:l-l->2:l-l-3 

1518 

0.2 

10 

162 

162 

0 

0 

Data l:l-l->2:l-l-4 

1518 

0.2 

10 

162 

162 

0 

0 

Data l:l-l->2:l-l-5 

1518 

0.2 

10 

162 

162 

0 

0 

Data l:l-l->2:l-l-6 

1518 

0.2 

10 

162 

162 

0 

0 

Data l:l-l->2:l-l-7 

1518 

0.2 

10 

162 

162 

0 

0 

Data l:l-l->2:l-l-8 

1518 

0.2 

10 

162 

162 

0 

0 

Data l:l-l->2:l-l-9 

1518 

0.2 

10 

162 

162 

0 

0 

Data 1:1-1->2:1-1-10 

1518 

0.2 

10 

162 

162 

0 

0 

Datal:l-l->2:l-l-ll 

1518 

0.2 

10 

162 

162 

0 

0 

Data 1:1-1->2:1-1-12 

1518 

0.2 

10 

162 

162 

0 

0 

Datal:l-1->2:1-1-13 

1518 

0.2 

10 

162 

162 

0 

0 

Data 1:1-1->2:1-1-14 

1518 

0.2 

10 

162 

162 

0 

0 

Data 1:1-1->2:1-1-15 

1518 

0.2 

10 

162 

162 

0 

0 

Datal:l-1->2:1-1-16 

1518 

0.2 

10 

162 

162 

0 

0 

Data 1:1-1->2:1-1-17 

1518 

0.2 

10 

162 

162 

0 

0 

Data 1:1-1->2:1-1-18 

1518 

0.2 

10 

162 

162 

0 

0 

Datal:l-1->2:1-1-19 

1518 

0.2 

10 

162 

162 

0 

0 

Data l:l-l->2:l-l-20 

1518 

0.2 

10 

162 

162 

0 

0 

Data l:l-l->2:1-1-21 

1518 

0.2 

10 

162 

162 

0 

0 

Data l:l-l->2:l-l-22 

1518 

0.2 

10 

162 

162 

0 

0 

Data l:l-l->2:l-l-23 

1518 

0.2 

10 

162 

161 

1 

0.61728 

Datal:l-l->2:l-l-24 

1518 

0.2 

10 

162 

161 

1 

0.61728 

Data l:l-l->2:l-l-25 

1518 

0.2 

10 

162 

162 

0 

0 

Table 25. PORTION OF LIGH1 

rPOINTE 

DATA RUN AT RAYTHEON 


70 








































Figure 36 is a graphic product of SmartBits. The graphic visually shows 
the throughput and frame loss of the infrastructure. The visual representation clearly 
shows a frame size of 1,518 Kbytes with a throughput of 20 Mbps. 



Throughput vs Frame Size 

Figure 37. LIGHTPOINTE THROUGHPUT VERSUS ERAME SIZE AT RAYTHEON 
b. SecNet-11 

Testing of an 802.1 lb technology (SecNet-11) was conducted on Eebruary 
2-3, 2004. The configuration was the same as described in Eield Test Two. The testing 
was conducted at a range of 6.7 kilometers. Each bridge was encrypted with a SecNet-11 
card. One side of the bridge was connected to the parabolic anteima and the other side of 
the bridge was connected the network. The special connectors interfacing the bridge and 
the parabolic antenna and the speed of the ports of the routers and the switches described 
in Eield Test Two apply in the configuration of this experiment. The channel setting for 
the bridge was channel eleven. 

It was raining on 2 Eebruary, the night of the baseline testing. Due to the 
late start, data collected on this day was limited. There were only three data points 
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collected using SolarWinds and one Iperf data point was eollected. The table below 
(Table 26) shows the data eollected on February 2-3 from the transfer data test monitored 
by SolarWinds. On the fourth run, the Iperf test was done in conjunction with the 
transfer data test. 




Run No, 

Media 

Size 

Time 

Throughput 

From 

To 

VOICE 

1 

802.11b 

lOM 


1.54M 

3.3 

1.2 

NO 

2 

802.11b 

25 M 

3'00" 

1.55M 

3.3 

1.2 

NO 

3 

802.11b 

126M 


1.62M 

3.3 

1.2 

NO 



Table 26. SECNET 11 SOEARWINDS DATA EEBRUARY 2-3 


The Iperf data was eollected prior to seeuring for the night on 2 Eebruary. 
The following represents the Iperf data collected: 


Client eonneeting to 192.168.1.3, TCP port 5001 
TCP window size: 63.0 KByte (default) 


[928] 

[ID] 

[928] 

[928] 

[928] 

[928] 

[928] 


loeal I92.I68.3.3 
Interval 
0.0- 5.0 sec 
5.0-10.0 sec 
10.0-15.0 sec 
15.0-20.2 sec 
0.0-21.1 sec 


port 1033 connected with 192.168.1.3 port 5001 


Transfer 
688 KBytes 
1.0 MBytes 
960 KBytes 
864 KBytes 
3.5 MBytes 


Bandwidth 
1.1 Mbits/sec 
1.6 Mbits/see 
1.5 Mbits/sec 
1.3 Mbits/see 
1.3 Mbits/see 


On 3 Eebruary, the wind was blowing at roughly 15 knots. The first 
couple of hours were spent ereeting the tent and securing the antennas at the remote site. 
The antenna at the remote site was tied off with a guy wire that was then seeured into the 
ground using tent stakes. The parabolie antenna at the remote site was very stable and 
did not move, but keeping the parabolie antenna stable on the roof of the Raytheon 
building was a ehallenge. The antenna was eventually secured by having an individual 
hold the antenna in the direction of the remote site. The data table above (Table 26) 
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shows the only data point taken using SolarWinds. The following Iperf data runs indicate 
lower throughput mainly because of the wind conditions. According to the Certified 
Wireless Network Administrator Official Study Guide, “Wind does not affect radio 
waves or an RF signal, but it can affect the positioning and mounting of outdoor 
antennas....A strong wind could easily move one or both antennas enough to completely 
degrade the signal between the two antennas. This effect is called ‘antenna wind 
loading. ”’45 The figure below shows an example of antenna wind loading (Figure 37). 



Beam arrives 
at receiver 



Beam misses 



Figure 3 8. ANTENNA WIND LOADING46 


Only two runs were conducted due to the bad wind conditions. In 
comparison to the night before when the wind was not as strong, the throughput was 
considerably less on the windy day. The following represents the data obtained from the 
Iperf test: 


Client connecting to 192.168.1.2, TCP port 5001 
TCP window size: 63.0 KByte (default) 


[928] local 192.168.3.3 port 1113 connected with 192.168.1.2 port 5001 
[ ID] Interval Transfer Bandwidth 

[928] 0.0-14.2 sec 72.0 KBytes 40.5 Kbits/sec 

45 McGraw-HilPOsborne, “Certified Wireless Network Administrator Offieial Study Guide (Exam 
PWO-100) Second Edition”, (Berkeley, California: Planet3 Wireless, Inc. 2003), pg 357. 

46 Ibid McGraw-Hill/Osbome, “Certified Wireless Network Administrator Official Study Guide 
(Exam PWO-100) Second Edition”, (Berkeley, California: Planet3 Wireless, Inc. 2003), pg 357. 
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[928] 14.2-14.2 sec 
[928] 14.2-15.1 sec 
[928] 15.1-20.0 sec 
[928] 0.0-20.8 sec 

SECOND RUN 

8.0 KBytes 

24.0 KBytes 

160 KBytes 

264 KBytes 

Inf s/sec 

228 Kbits/sec 

258 Kbits/sec 
lOI Kbits/sec 

Client connecting to 192.168.1.2, TCP port 5001 

TCP window size: 63.0 KByte (default) 

[928] local 192.168.3.3 

port 1114 connected with 192.168.1.2 port 5001 

[ ID] Interval 

Transfer 

Bandwidth 

[928] 0.0- 5.2 sec 

360 KBytes 

549 Kbits/sec 

[928] 5.2-10.1 sec 

280 KBytes 

464 Kbits/sec 

[928] 10.1-15.3 sec 

320 KBytes 

486 Kbits/sec 

[928] 15.3-20.1 sec 

272 KBytes 

460 Kbits/sec 

[928] 0.0-33.8 sec 

1.2 MBytes 

292 Kbits/sec 


On the following day a different technology, 802.16, was tested along with 
FSO. The 802.16 company was Ensemble Communications and the FSO company was 
Terabeam. This testing is explained in the next two section of this thesis. 

c. Ensemble 

Ensemble Communications brought equipment that utilizes 802.16 
technology. As described earlier in this thesis, 802.16 technology is used for WANs. In 
the commercial sector, 802.16 is used for backhaul broadband wireless connectivity for 
many service providers. The personnel who supported this evolution were Jeff 
Nightingale, Sales Director; Corey Koberg, Engineer; and Jerry Shirey, Field Technician. 
As discussed in the General Dynamics exercise. Field Test Two, Ensemble’s system was 
ATM based which means that special configurations for both local area networks needed 
to take place prior to any testing. At the Mobile Research Facility, a single port ATM 
OC-3 Single-mode Intermediate Reach NM card for the Cisco 3745 router was 
configured for the router. The 16200 Hub Station was connected to the port on this card 
with a single-mode fiber cable. At the remote site, the 320 Multiplexer was connected to 
the remote Cisco 3745 router with CAT-5 cable. Similar to Field Test Two, a Fiberless 
282 Series ODU was utilized for the antenna. 
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The series of tests that were conducted with Ensemble started with Iperf 
testing, followed by SolarWinds testing, and concluded with SmartBits testing. The Iperf 
testing was conducted after the two ends were configured to handle an ATM based 
network. The Iperf data is represented below: 


Server listening on TCP port 5001 
TCP window size: 0.1 MByte 


[920] local 192.168.3.3 port 5001 connected with 192.168.1.2 port 1038 

[ ID] Interval Transfer Bandwidth 

[920] 0.0-1.0 sec 2.4 MBytes 19.4 Mbits/sec 

[920] 1.0-2.0 sec 2.8 MBytes 22.7 Mbits/sec 

[920] 2.0-3.0 sec 3.0 MBytes 24.0 Mbits/sec 

[920] 3.0-4.0 sec 3.1 MBytes 24.6 Mbits/sec 

[920] 4.0- 5.0 sec 3.2 MBytes 25.5 Mbits/sec 

[920] 5.0-6.0 sec 4.0 MBytes 32.1 Mbits/sec 

[920] 6.0- 7.0 sec 4.5 MBytes 35.9 Mbits/sec 

[920] 7.0-8.0 sec 4.5 MBytes 35.9 Mbits/sec 

[920] 8.0- 9.0 sec 4.5 MBytes 35.9 Mbits/sec 

[920] 9.0-10.0 sec 4.5 MBytes 35.9 Mbits/sec 

[920] 0.0-10.0 sec 36.5 MBytes 29.2 Mbits/sec 


Server listening on TCP port 5001 
TCP window size: 0.1 MByte 


[920] local 192.168.3.3 port 5001 connected with 192.168.1.2 port 1041 

[ ID] Interval Transfer Bandwidth 

[920] 0.0-1.0 sec 3.3 MBytes 26.2 Mbits/sec 

[920] 1.0-2.0 sec 4.5 MBytes 36.0 Mbits/sec 

[920] 2.0- 3.0 sec 4.5 MBytes 35.9 Mbits/sec 

[920] 3.0- 4.0 sec 3.9 MBytes 30.8 Mbits/sec 

[920] 4.0-5.0 sec 3.1 MBytes 24.5 Mbits/sec 

[920] 5.0-6.0 sec 3.1 MBytes 24.2 Mbits/sec 

[920] 6.0-7.0 sec 3.1 MBytes 25.7 Mbits/sec 

[920] 7.0- 8.0 sec 3.2 MBytes 25.6 Mbits/sec 

[920] 8.0- 9.0 sec 3.4 MBytes 27.3 Mbits/sec 

[920] 9.0-10.0 sec 3.7 MBytes 29.9 Mbits/sec 

[920] 0.0-10.0 sec 35.9 MBytes 28.6 Mbits/sec 
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The Iperf data for the first run indieated an average throughput of 29.2 Mbps between the 
two sites at a distance of 6.7 kilometers. The Iperf data for the second run indicated a 
throughput of 28.6 Mbps between sites. 


The measurements observed using SolarWinds differ from the readings 
indicated by Iperf. The disparity is due to the type of data that is sent across the link. In 


the Iperf test, the size of the data being transferred is a consistent steady stream of data 
going across the network. In the transfer data test monitored by SolarWinds, the data 
going across the network differs in size of the file and the type of data. The SolarWinds 


results are represented below (Table 27). 



Run No, 

Media 

Size 

Time 

Throughput 

Packet Loss (“/o) 

VOICE 

VIDEO 

1 

802.16 

1.5 M 

1" 

2.2M 

0 

NO 

NO 

2 

802.16 

5 M 

8" 

6.28M 

0 

NO 

NO 

3 

802.16 

lOM 

13" 

7.84M 

0 

NO 

NO 

5 

802.16 

75 M 

1'20" 

7.9M 

0 

NO 

NO 

6 

802.16 

150 M 

3'00" 

7M 

0 

NO 

NO 






7 

802.16 

video 


6.46M 

0 

YES 

YES 

8 

802.16 

video 


3M 

0 

YES 

YES 

9 

802.16 

video both 

sides 

6M 

0 

YES 

YES 

10 

802.16 

video 

and 75M 

7M 

0 

YES 

YES 


Table 27. ENSEMBLE RAW SOLARWINDS DATA AT RAYTHEON 


The data obtained using SmartBits resembles the data obtained from using 
Iperf. Lour different runs were tested using SmartBits. The first run was to observe 
where the maximum throughput was located. The second run was to determine where 
SolarWinds was dropping the link (SolarWinds would indicate the link was not 
established, however, the link was still up because we were able to use VoIP). The third 
run was to measure the amount of packet loss when the throughput was doubled. The 
fourth run was to examine the link with an over-saturation of data. 

The maximum throughput was located in a range of 20-30 Mbps, similar 
to what Iperf produced. The data table below shows an excerpt of the data obtained from 

the SmartBits program in the first run (Table 28). 
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Total 

10 

10 

16218 

16218 

0 

0 

Data Group 

N/A 

10 

15900 

15900 

0 

0 

TEST Group 

N/A 

10 

318 

318 

0 

0 

Total 

20 

20 

32436 

32433 

3 

0.00925 

Data Group 

N/A 

20 

31800 

31797 

3 

0.00943 

TEST Group 

N/A 

20 

636 

636 

0 

0 

Total 

30 

20 

48756 

37589 

11167 

22.90385 

Data Group 

N/A 

20 

47800 

36867 

10933 

22.87238 

TEST Group 

N/A 

20 

956 

722 

234 

24.47699 

FrameSize 

1518 


Throughput (% max load) 

20 

Frame Loss (%) 

0.00925 


Table 28. ENSEMBLE SMAR' 


BITS DATA AT RAYTHEON 


The figure below shows a graphie representation of the throughput of 
SmartBits. This graphie representation indieates there was no paeket loss in the above 
test when the load was at 20 Mbps (Eigure 38). 



Throughput vs Frame Size 

Eigure 39. ENSEMBLE SMART BITS GRAPHICS AT RAYTHEON 
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The third run using Smart Bits was an experiment to determine the amount 
of paeket loss if the throughput load was doubled. The data indieated that when the 
throughput was doubled (the amount of data being sent was two times the size of the 20- 
30 Mbps throughput being allowed by Ensemble’s equipment), the paeket loss inereased. 


The table below indicates the results obtained on the third run (Table 29). 


Total 

10 

10 

16218 

16218 

0 

0 

Data Group 

N/A 

10 

15900 

15900 

0 

0 

TEST Group 

N/A 

10 

318 

318 

0 

0 

Total 

20 

20 

32436 

32435 

1 

0.00308 

Data Group 

N/A 

20 

31800 

31799 

1 

0.00314 

TEST Group 

N/A 

20 

636 

636 

0 

0 

Total 

30 

30 

48756 

37587 

11169 

22.90795 

Data Group 

N/A 

30 

47800 

36841 

10959 

22.92678 

TEST Group 

N/A 

30 

956 

746 

210 

21.96653 

Total 

40 

40 

64974 

37571 

27403 

42.17533 

Data Group 

N/A 

40 

63700 

36814 

26886 

42.20722 

TEST Group 

N/A 

40 

1274 

757 

517 

40.58085 

Total 

50 

40 

81192 

37556 

43636 

53.74421 

Data Group 

N/A 

40 

79600 

36908 

42692 

53.63317 

TEST Group 

N/A 

40 

1592 

648 

944 

59.29648 

FrameSize 

1518 


Throughput (% max load) 

40 

Frame Loss (%) 

42.17533 


Table 29. ENSEMBLE SMARTBITS DATA (X2) AT RAYTHEON 


The graphic illustration below compares the throughput and the frame loss 
during the third run (Eigure 39). 
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Throughput vs Frame Size 

Figure 40. ENSEMBLE PACKET LOSS AT RAYTHEON 

The seeond run will be eovered in the Findings and Analysis portion of the 
thesis beeause these runs foeused on why the link dropped out between the 30 to 40 Mbps 
phase of the experiment. The fourth run will be eovered in the Findings and Analysis 
portion also beeause the data is similar to the results obtained in the third run (saturation 
of the network). The third run indicated that when the network is oversaturated, then an 
increase of packet loss is observed. This is to say that there is an upper limit of data that 
can be processed by the medium providing the link between the networks. Once this 
upper limit is reached then the network will experience packet loss. 

FSO was also tested on the same day. The name of the company tested 
was Terabeam from Redmond, Washington. 

d. Terabeam 

Terabeam produces FSO equipment as well as Radio Frequency (RF) 
equipment. Their RF product is a 60 GHz millimeter wave (MMW) system. The FSO 
product that was brought was the Elliptica. The difference between this company and the 
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other companies is that Terabeam’s product uses only one laser at the 1550 nanometer 
wavelength. Other impressive features of the Elliptica are the optical scope, the auto 
tracking feature, and the easy setup. The optical scope was used to align the two lasers. 
The alignment process took a total of 5 minutes. The auto-tracking feature compensates 
for the swaying of buildings or the movement of the distant laser. The setup of the 
Elliptica was done quickly and efficiently. The Elliptica comes with deployable mounts 
used to set the optical head (Eigure 40). 



Eigure 41. TERABEAM EELIPTICA 


The Terabeam personnel who supported the Raytheon Testing were Pascal 
Boudreau, Eric Ruberg, and Carrie Cornish. Their level of expertise and professionalism 
shined throughout the testing evolution. 

Similar to the other products tested, Terabeam followed the same series of 
tests. The series of tests consisted of taking data from an Iperf test, a file transfer test 
(SolarWinds data), and a SmartBits test. When the Iperf test was conducted, setting the 
window size of the data being transferred was very important. If the window size was 
too low, the data throughput would result in a lower value. An example of this is 
demonstrated in the Bindings and Analysis portion of the thesis. The Iperf data obtained 


80 







on Terabeam was one of the highest obtained at Raytheon. The data below represents the 
Iperf data taken on Terabeam: 


Server listening on TCP port 5001 
TCP window size: 0.1 MByte 


[920] 

[ID] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 


loeal 192.168.3.3 port 5001 eonneeted with 192.168.1.2 port 1059 


Interval 

Transfer 

Bandwidth 

0.0- 1.0 sec 

8.7 MBytes 

69.7 Mbits/sec 

1.0- 2.0 sec 

9.8 MBytes 

78.4 Mbits/sec 

2.0- 3.0 sec 

9.7 MBytes 

77.4 Mbits/sec 

3.0- 4.0 sec 

10.7 MBytes 

85.3 Mbits/sec 

4.0- 5.0 sec 

10.2 MBytes 

81.3 Mbits/sec 

5.0- 6.0 sec 

9.5 MBytes 

76.3 Mbits/sec 

6.0- 7.0 sec 

10.9 MBytes 

88.3 Mbits/sec 

7.0- 8.0 sec 

10.9 MBytes 

87.2 Mbits/sec 

8.0- 9.0 sec 

11.3 MBytes 

90.2 Mbits/sec 

9.0-10.0 sec 

10.9 MBytes 

87.0 Mbits/sec 

0.0-10.0 sec 

10.3 MBytes 

82.1 Mbits/sec 


The next series of testing involved the transfer of data files that would be 
found on the battlefield. These files inelude Power Point, Excel, Word, Adobe, and basic 
text files being transferred from one computer in one local area network to another 
computer in another local area network. SolarWinds was used to monitor the data 
transfer. There were nine different runs conducted during this data testing evolution. 
The first seven runs were simple data transfer between the two local area networks 
measuring throughput and time for the data to be transferred. The next series of data 
runs, VoIP and video programs were running on the computers while executing the data 
file transfer test. The purpose of these runs was to see if other applications had an effect 
on the throughput of the data being transferred. The result was that there was no loss in 
audio quality in the VoIP and no loss in the video quality of the videos being played on 
the computers during the transfer. The data below represents the data transfer from one 
local area network to the other local area network via Terabeam’s link (Table 30). 
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Run No. 

Media 

Size 

Time 

Throughput 

Paeket Loss (%) 

VOICE 

VIDEO 

1 

FSO 

1.5 M 

1" 

2.2M 

0 

NO 

NO 

2 

FSO 

5M 

6" 

7.29M 

0 

NO 

NO 

3 

FSO 

10 M 

2" 

14M 

0 

NO 

NO 

4 

FSO 

25 M 

1" 

18M 

0 

NO 

NO 

5 

FSO 

75 M 

o 

OO 

24M 

0 

NO 

NO 

6 

FSO 

DOM 

1T2" 

35M 

0 

NO 

NO 

7 

FSO 

300 M 

3'56" 

36M 

0 

NO 

NO 

8 

FSO 

5M 


6M 

0 

YES 

YES 

9 

FSO 

5M 


6M 

0 

YES 

YES 


Table 30. TERABEAM’S SOLAR WIND DATA AT RAYTHEON 


There were two runs using SmartBits for the Terabeam produet. The first 
run was conducted to measure the data transfer between the two LANs. The data is 
represented below (Table 31). 
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Total 

10 

10 

16218 

16210 

8 

0.04933 

Data Group 

N/A 

10 

15900 

15892 

8 

0.05031 

Smart Bit Group 

N/A 

10 

318 

318 

0 

0 

Total 

20 

20 

32436 

32433 

3 

0.00925 

Data Group 

N/A 

20 

31800 

31797 

3 

0.00943 

Smart Bit Group 

N/A 

20 

636 

636 

0 

0 

Total 

30 

30 

48756 

48740 

16 

0.03282 

Data Group 

N/A 

30 

47800 

47784 

16 

0.03347 

Smart Bit Group 

N/A 

30 

956 

956 

0 

0 

Total 

40 

40 

64974 

64963 

11 

0.01693 

Data Group 

N/A 

40 

63700 

63690 

10 

0.0157 

Smart Bit Group 

N/A 

40 

1274 

1273 

1 

0.07849 

Total 

50 

50 

81192 

81169 

23 

0.02833 

Data Group 

N/A 

50 

79600 

79579 

21 

0.02638 

Smart Bit Group 

N/A 

50 

1592 

1590 

2 

0.12563 

Total 

60 

60 

97512 

97486 

26 

0.02666 

Data Group 

N/A 

60 

95600 

95576 

24 

0.0251 

Smart Bit Group 

N/A 

60 

1912 

1910 

2 

0.1046 

Total 

70 

70 

113730 

113652 

78 

0.06858 

Data Group 

N/A 

70 

111500 

111424 

76 

0.06816 

Smart Bit Group 

N/A 

70 

2230 

2228 

2 

0.08969 

Total 

80 

80 

129948 

129877 

71 

0.05464 

Data Group 

N/A 

80 

127400 

127329 

71 

0.05573 

Smart Bit Group 

N/A 

80 

2548 

2548 

0 

0 

Total 

90 

90 

146268 

146174 

94 

0.06427 

Data Group 

N/A 

90 

143400 

143309 

91 

0.06346 

Smart Bit Group 

N/A 

90 

2868 

2865 

3 

0.1046 

Total 

100 

100 

162486 

161946 

540 

0.33234 

Data Group 

N/A 

100 

159300 

158764 

536 

0.33647 

Smart Bit Group 

N/A 

100 

3186 

3182 

4 

0.12555 

FrameSize 

1518 






Throughput (% max load) 

100 






Frame Loss (%) 

0.33234 







Table 31. TERABEAM’S SMART BITS DATA TRANSFER 


The graphical representation shown below is a graph of throughput versus 
frame size (Figure 41). 












































Throughput vs Frame Size 

Figure 42. TERABEAM GRAPHICAE DATA REPRESENTATION 

The next run of testing ineluded the VoIP funetion of SmartBits. The 
SmartBits equipment generated data paekets along with VoIP paekets aeross the 
Terabeam link. The data below represents the SmartBits data obtained while employing 
the VoIP funetion with Terabeam’s link (Table 32). 
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Total 

10 

10 

16224 

16221 

3 

0.01849 

Data Group 

N/A 

10 

15600 

15597 

3 

0.01923 

Smart Bit Group 

N/A 

10 

312 

312 

0 

0 

VoIP Group 

N/A 

10 

312 

312 

0 

0 

Total 

20 

20 

32448 

32435 

13 

0.04006 

Data Group 

N/A 

20 

31200 

31187 

13 

0.04167 

Smart Bit Group 

N/A 

20 

624 

624 

0 

0 

VoIP Group 

N/A 

20 

624 

624 

0 

0 

Total 

30 

30 

48672 

48657 

15 

0.03082 

Data Group 

N/A 

30 

46800 

46785 

15 

0.03205 

Smart Bit Group 

N/A 

30 

936 

936 

0 

0 

VoIP Group 

N/A 

30 

936 

936 

0 

0 

Total 

40 

40 

65000 

64990 

10 

0.01538 

Data Group 

N/A 

40 

62500 

62490 

10 

0.016 

Smart Bit Group 

N/A 

40 

1250 

1250 

0 

0 

VoIP Group 

N/A 

40 

1250 

1250 

0 

0 

Total 

50 

50 

81224 

81199 

25 

0.03078 

Data Group 

N/A 

50 

78100 

78077 

23 

0.02945 

Smart Bit Group 

N/A 

50 

1562 

1561 

1 

0.06402 

VoIP Group 

N/A 

50 

1562 

1561 

1 

0.06402 

Total 

60 

60 

97448 

97425 

23 

0.0236 

Data Group 

N/A 

60 

93700 

93677 

23 

0.02455 

Smart Bit Group 

N/A 

60 

1874 

1874 

0 

0 

VoIP Group 

N/A 

60 

1874 

1874 

0 

0 

Total 

70 

70 

113776 

113683 

93 

0.08174 

Data Group 

N/A 

70 

109400 

109308 

92 

0.0841 

Smart Bit Group 

N/A 

70 

2188 

2187 

1 

0.0457 

VoIP Group 

N/A 

70 

2188 

2188 

0 

0 

Total 

80 

80 

130000 

129940 

60 

0.04615 

Data Group 

N/A 

80 

125000 

124942 

58 

0.0464 

Smart Bit Group 

N/A 

80 

2500 

2498 

2 

0.08 

VoIP Group 

N/A 

80 

2500 

2500 

0 

0 

Total 

90 

90 

146224 

146143 

81 

0.05539 

Data Group 

N/A 

90 

140600 

140525 

75 

0.05334 

Smart Bit Group 

N/A 

90 

2812 

2808 

4 

0.14225 

VoIP Group 

N/A 

90 

2812 

2810 

2 

0.07112 

Total 

100 

100 

162448 

161850 

598 

0.36812 

Data Group 

N/A 

100 

156200 

155618 

582 

0.3726 

Smart Bit Group 

N/A 

100 

3124 

3118 

6 

0.19206 

VoIP Group 

N/A 

100 

3124 

3114 

10 

0.3201 

FrameSize 

1518 


Throughput (% max load) 

100 

Frame Loss (%) 

0.36812 


Table 32. TERABEAM VOIP SMART BITS DATA AT RAYTHEON 





















































Terabeam was used to test the KG- 235s. The KG- 235 is a bulk INE that 
is used to secure the link between the two sites. The KG-235 was placed into the network 
as described in the previous testing at General Dynamics. 

e. Crypto (INE) 

The placement of the In-Line Encryptor (INE) was between the Terabeam 
link and the local area network’s Cisco 3550 switch. The Cisco 3745 routers were 
removed from the network in order to make the KG-23 5 s work properly. The KG-235s 
functioned as routers for the two networks. The KG-235s were assigned Internet 
Protocol network addresses on different subnets in order for the two networks to 
communicate with each other. A CAT-5 cable was used to connect one side (one of two 
Ethernet ports on the KG-235) to the Elliptica from Terabeam. The other side (second 
Ethernet port) of the KG-235 was connected to the local area network’s Cisco 3550 
switch with CAT-5 cable. The laptops, configured on the same subnet as the KG-235, 
were connected to the switch. 

Two runs were conducted using the Iperf test. The first run was conducted 
with max window size set for the computers to handle maximum throughput across the 
link. The data below represents the first run of data. 


Server listening on TCP port 5001 
TCP window size; 0.1 MByte 


[920] 

[ID] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 


local 192.168.3.3 port 5001 connected with 192.168.1.2 port 1072 


Interval 

Transfer 

Bandwidth 

0.0- 1.0 sec 

0.6 MBytes 

4.4 Mbits/sec 

1.0- 2.0 sec 

0.5 MBytes 

4.0 Mbits/sec 

2.0- 3.0 sec 

0.6 MBytes 

4.4 Mbits/sec 

3.0- 4.0 sec 

0.5 MBytes 

4.1 Mbits/sec 

4.0- 5.0 sec 

0.5 MBytes 

4.4 Mbits/sec 

5.0- 6.0 sec 

0.4 MBytes 

3.4 Mbits/sec 

6.0- 7.0 sec 

0.5 MBytes 

4.4 Mbits/sec 

7.0- 8.0 sec 

0.5 MBytes 

3.7 Mbits/sec 

8.0- 9.0 sec 

0.5 MBytes 

4.3 Mbits/sec 

9.0-10.0 sec 

0.4 MBytes 

3.4 Mbits/sec 

0.0-10.1 sec 

5.1 MBytes 

4.1 Mbits/sec 
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During the second run the settings on the INE itself were maximized to 
full capacity and the following results were achieved; 


Server listening on TCP port 5001 
TCP window size: 0.1 MByte 


[920] local 192.168.3.3 

port 5001 connected with 192.168.1.2 port 1036 

[ ID] Interval 

Transfer 

Bandwidth 

[920] 0.0- 1.3 sec 

0.1 MBytes 

0.8 Mbits/sec 

[920] 1.3-2.1 sec 

0.0 MBytes 

0.1 Mbits/sec 

[920] 2.1-3.0 sec 

0.5 MBytes 

4.0 Mbits/sec 

[920] 3.0-4.0 sec 

0.3 MBytes 

2.6 Mbits/sec 

[920] 4.0- 5.0 sec 

0.5 MBytes 

4.1 Mbits/sec 

[920] 5.0- 6.0 sec 

0.5 MBytes 

4.2 Mbits/sec 

[920] 6.0- 7.0 sec 

0.5 MBytes 

3.8 Mbits/sec 

[920] 7.0-8.0 sec 

0.5 MBytes 

4.0 Mbits/sec 

[920] 8.0-9.0 sec 

0.5 MBytes 

3.9 Mbits/sec 

[920] 9.0-10.0 sec 

0.5 MBytes 

3.9 Mbits/sec 

[920] 0.0-10.4 sec 

4.0 MBytes 

3.1 Mbits/sec 


It was discovered during the second run that the INE needed the latest 
firmware in order to provide a larger throughput for the network. This information was 
not known prior to the experiment, which limited a thorough examination of the INE. 

Eater in the week, another ESO company named IBONA tested the link 
with the KG-235S. Here again the window size was manipulated in order to achieve 
maximum throughput across the link. The maximum throughput obtained using the KG- 
235 is represented below. 

Encrypted with KG-235 

Server listening on TCP port 5001 

TCP window size: 0.1 MByte 


[920] 

[ID] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 


local 192.168.1.25 
Interval 
0.0- 1.0 sec 
1.0- 2.0 sec 
2.0- 3.0 sec 
3.0- 4.0 sec 
4.0- 5.0 sec 
5.0- 6.0 sec 
6.0- 7.0 sec 


port 5001 connected with 192.168.3.25 port 1808 


Transfer 
0.6 Mbytes 
0.6 MBytes 
0.6 MBytes 
0.6 MBytes 
0.6 MBytes 
0.6 MBytes 
0.6 MBytes 


Bandwidth 
4.8 Mbits/sec 
5.0 Mbits/sec 
5.0 Mbits/sec 
5.0 Mbits/sec 
5.0 Mbits/sec 
5.0 Mbits/sec 
5.0 Mbits/sec 


87 







[920] 7.0-8.0 sec 
[920] 8.0-9.0 sec 
[920] 9.0-10.0 sec 
[920] 0.0-10.1 sec 


0.6 MBytes 
0.6 MBytes 
0.6 MBytes 
6.3 MBytes 


5.1 Mbits/sec 
4.9 Mbits/sec 
5.0 Mbits/sec 
5.0 Mbits/sec 


The following day the authors introduced a new technology to the field- 
testing site, Radio Frequency Module (RFM). 

f. RFM 

The RFM, described earlier in the General Dynamics testing portion of the 
thesis, is produced by Ceragon Networks. GDDS packages the product in a deployable 
case with a Cisco 2950 switch for GDDS customers. The hardened case and microwave 
dish is field expedient to withstand a rugged military environment. GDDS supported the 
experiment with Jon Seime and William Dean. 

The series of tests conducted with the RFM involved the RFM conducting 
an Iperf test, a data transfer test monitored by SolarWinds, and a SmartBits test. After 
the RFM was tested, MRV’s Terescope 3000 (Free Space Optics product) was tested. 
This testing is described later in the thesis. Immediately following the FSO test, MRV’s 
OptiSwitch was tested. The MRV’s OptiSwitch was used in combination with the RFM 
and the FSO. This testing is described later in the thesis as well. 

During the Iperf testing with the RFM, the students conducted several data 
runs to find the appropriately sized packet that would maximize throughput for data file 
transfers. The Iperf data below represents the maximum throughput data gathered across 
the RFM link. 


Server listening on TCP port 5001 
TCP window size: 0.1 MByte 


[920] local 192.168.3.3 
[ ID] Interval 
[920] 0.0- 1.0 sec 
[920] 1.0-2.0 sec 
[920] 2.0-3.0 sec 
[920] 3.0-4.0 sec 
[920] 4.0- 5.0 sec 
[920] 5.0- 6.0 sec 


port 5001 connected with 192.168. 


Transfer 
11.0 MBytes 
11.1 MBytes 
10.6 MBytes 
10.6 MBytes 
10.6 MBytes 
11.3 MBytes 


Bandwidth 

88.2 Mbits/sec 
88.6 Mbits/sec 

84.3 Mbits/sec 
85.0 Mbits/sec 
84.9 Mbits/sec 
90.2 Mbits/sec 


1 


.2 port 1090 
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[920] 

6.0- 7.0 sec 

11.2 

[920] 

7.0- 8.0 sec 

11.3 

[920] 

8.0- 9.0 sec 

11.3 

[920] 

9.0-10.0 sec 

11.3 

[920] 

0.0-10.0 sec 

no 


MBytes 90.2 Mbits/sec 

MBytes 90.2 Mbits/sec 

MBytes 90.2 Mbits/sec 

MBytes 90.2 Mbits/sec 

MBytes 88.3 Mbits/sec 


The transfer of data test monitored by SolarWinds illustrated a maximum 
throughput of 40 Mbps. During this series of testing, there were 9 runs completed in all. 
The first run was only a 300 Mbyte data file transferred from one local area network to 
another. During the data file transfer, VoIP quality was monitored by the clarity of the 
voice conversation while the transfer was occurring. For the remainder of the data file 
transfer test, along with VoIP, there was a video camera transmitting data across the li nk . 
Additionally, a video file was being played on one of the computers that was transferring 
data files to the distant end of the network. The data gathered is represented in the table 
below (Table 33). 


1 Run No. 1 Media 

Size 

Time 

Throughput 

Loss (%) 

VOICE 

VIDEO 1 








1 1 

Microwave 

300 M 

1T5" 

40M 

0 

YES 

NO 1 

2 

Microwave 

1.5 M 

1" 

2.7M 

0 

YES 

YES 

3 

Microwave 

5 M 

2" 

7.8M 

0 

YES 

YES 

4 

Microwave 

10 M 

5" 

15M 

0 

YES 

YES 

5 

Microwave 

75 M 

17" 

32M 

0 

YES 

YES 

6 

Microwave 

150 M 

38" 

36M 

0 

YES 

YES 

7 

Microwave 

300 M 

1'20" 

33M 

0 

YES 

YES 

8 

Microwave 

600 M 

3T4" 

39M 

0 

YES 

YES 

9 

Microwave 

1.2 GIG 

6'30" 

36M 

0 

YES 

YES 


Table 33. RFM SOLARWINDS DATA AT RAYTHEON 


During the SmartBits test, SmartBits simulated 20 VoIP phone 
conversations going across the network. Additionally, SmartBits simulated 100 
computers passing information simultaneously across the network. The test revealed a 
less than 1 % packet loss across the network as the load on the network increased in 10 
Mbyte increments. The table below shows the information gathered during this series of 
testing (Table 34). 
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Total 

10 

10 

26000 

26000 

0 

0 

Data Group 

N/A 

10 

9300 

9280 

20 

0.21505 

VoIP Group 

N/A 

10 

13000 

13000 

0 

0 

Total 

20 

20 

39000 

39000 

0 

0 

Data Group 

N/A 

20 

18600 

18560 

40 

0.21505 

VoIP Group 

N/A 

20 

13000 

13000 

0 

0 

Total 

30 

30 

52000 

52000 

0 

0 

Data Group 

N/A 

30 

27880 

27840 

40 

0.14347 

VoIP Group 

N/A 

30 

13000 

13000 

0 

0 

Total 

40 

40 

65000 

65000 

0 

0 

Data Group 

N/A 

40 

37160 

37120 

40 

0.10764 

VoIP Group 

N/A 

40 

13000 

13000 

0 

0 

Total 

50 

50 

91000 

91000 

0 

0 

Data Group 

N/A 

50 

55720 

55700 

20 

0.03589 

VoIP Group 

N/A 

50 

13000 

13000 

0 

0 

Total 

60 

60 

104000 

104000 

0 

0 

Data Group 

N/A 

60 

65000 

65000 

0 

0 

VoIP Group 

N/A 

60 

13000 

13000 

0 

0 

Total 

70 

70 

117000 

117000 

0 

0 

Data Group 

N/A 

70 

74300 

74280 

20 

0.02692 

VoIP Group 

N/A 

70 

13000 

13000 

0 

0 

Total 

80 

80 

130000 

130000 

0 

0 

Data Group 

N/A 

80 

83600 

83560 

40 

0.04785 

VoIP Group 

N/A 

80 

13000 

13000 

0 

0 

Total 

90 

90 

156000 

156000 

0 

0 

Data Group 

N/A 

90 

102160 

102120 

40 

0.03915 

VoIP Group 

N/A 

90 

13000 

13000 

0 

0 

Total 

too 

100 

169000 

169000 

0 

0 

Data Group 

N/A 

100 

111440 

111400 

40 

0.03589 

VoIP Group 

N/A 

100 

13000 

13000 

0 

0 


Table 34. RFM SMART BITS DATA AT RAYTHEON 


As mentioned earlier in this seetion, FSO was tested on the same day as 
the RFM. The FSO eompany was MRV. Founded in 1988, MRV’s eorporate 
headquarters is in Chatsworth, California.47 

g. MRV 

The personnel that supported the evolution were Tim Kcehowski, Direetor 
of Federal Sales; Fevon Fayson, Teehnieal Support Engineering Manager; and Isaae 
Kim, Direetor of FSO. Mr. Fayson diligently set up and aligned the Tereseope 5000 OC- 


47 http://archive.mrv.com/corporate/profile.php 
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3 link heads. The environment was a metropolitan area spanning a distance between sites 
of 6,700 meters. The weather was very windy with partly sunny skies and a temperature 
in the mid 60’s. 

The data collected during MRV’s Terescope test involved the Iperf test, 
the data transfer test monitored by SolarWinds, and the SmartBits test. Several runs of 
the Iperf test were conducted. The reason for several runs was that the soft rooftop on 
Raytheon’s building, where the Terescope was mounted, and people walking around the 
Terescope caused enough movement to the scope to take it out of alignment. This will be 
addressed by MRV adding new advanced tracking into their FSO system. The Terescope 
was secured with concrete blocks in order to stabilize it on top of the building. The Iperf 
data below represents the maximum data throughput via MRV’s link. 


Server listening on TCP port 5001 
TCP window size: 0.1 MByte 


[920] 

[ID] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 


local 192.168.3.3 port 5001 connected with 192.168.1.2 port 1063 


Interval 

Transfer 

Bandwidth 

0.0- 1.0 sec 

11.1 MBytes 

88.3 Mbits/sec 

1.0- 2.0 sec 

11.2 MBytes 

89.8 Mbits/sec 

2.0- 3.0 sec 

11.2 MBytes 

89.9 Mbits/sec 

3.0- 4.0 sec 

11.2 MBytes 

89.7 Mbits/sec 

4.0- 5.0 sec 

11.3 MBytes 

89.9 Mbits/sec 

5.0- 6.0 sec 

11.2 MBytes 

89.7 Mbits/sec 

6.0- 7.0 sec 

11.1 MBytes 

89.9 Mbits/sec 

7.0- 8.0 sec 

11.3 MBytes 

89.9 Mbits/sec 

8.0- 9.0 sec 

11.2 MBytes 

89.7 Mbits/sec 

9.0-10.0 sec 

11.3 MBytes 

90.1 Mbits/sec 

0.0-10.0 sec 

112 MBytes 

89.7 Mbits/sec 


The data file transfer test monitored by SolarWinds consisted of a total of 
18 runs. The first series of runs consisted of data files transferred from one local area 
network to another. The data files ranged from 1.5 Mbytes to 1.2 Gbytes in size. The 
second series of runs consisted of data file transfers while VoIP was running as the data 
files were transferred from one local area network to another. The last series of runs 
consisted of data files being transferred while VoIP and video were running as the data 
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files were being transferred. The table below represents the data obtained from the data 
file transfer test using SolarWinds (Table 35). 



Run No. 

Media 

Size 

Time 

Throughput 

Loss (%) 

VOICE 

VIDEO 

1 

FSO 

1.5 M 

1" 

2.8M 

0 

NO 

NO 

2 

FSO 

5 M 

1" 

7.92M 

0 

NO 

NO 

3 

FSO 

10 M 

2" 

15M 

0 

NO 

NO 

4 

FSO 

75 M 

15" 

50M 

0 

NO 

NO 

5 

FSO 

150 M 

33" 

46M 

0 

NO 

NO 

6 

FSO 

300 M 

1'03" 

47M 

0 

NO 

NO 

7 

FSO 

600 M 

2T2" 

50M 

0 

NO 

NO 

8 

FSO 

1.2 GIG 

4'20" 

53M 

3 

NO 

NO 


9 

FSO 

1.5 M 

1" 

6M 

0 

YES 

NO 

10 

FSO 

5 M 

1" 

8M 

0 

YES 

NO 

11 

FSO 

10 M 

2" 

15M 

0 

YES 

NO 

12 

FSO 

75 M 

16" 

59M 

0 

YES 

NO 

13 

FSO 

150 M 

32" 

50M 

0 

YES 

NO 

14 

FSO 

300 M 

59" 

50m 

0 

YES 

NO 

15 

FSO 

600 M 

2'50" 

40m 

0 

YES 

NO 


16 

FSO 

1.5 M 

1" 

6M 

0 

YES 

YES 

17 

FSO 

5 M 

1" 

8M 

0 

YES 

YES 

18 

FSO 

10 M 

2" 

15M 

0 

YES 

YES 


Table 35. MRV’S SOLARWINDS DATA AT RAYTHEON 


The final test conducted using only MRV’s link was a SmartBits test. 
SmartBits generated simulated data being transferred across the link. The simulated data 
consisted of 100 computers passing information across the network plus 20 simulated 
VoIP phone conversations going across the network. The table below is an excerpt of the 
data obtained from SmartBits (Table 36). 
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Total 

10 

10 

26000 

26000 

0 

0 

Data Group 

N/A 

10 

13000 

13000 

0 

0 

VoIP Group 

N/A 

10 

13000 

13000 

0 

0 

Total 

20 

20 

39000 

39000 

0 

0 

Data Group 

N/A 

20 

26000 

26000 

0 

0 

VoIP Group 

N/A 

20 

13000 

13000 

0 

0 

Total 

30 

30 

52000 

52000 

0 

0 

Data Group 

N/A 

30 

39000 

39000 

0 

0 

VoIP Group 

N/A 

30 

13000 

13000 

0 

0 

Total 

40 

40 

65000 

65000 

0 

0 

Data Group 

N/A 

40 

52000 

52000 

0 

0 

VoIP Group 

N/A 

40 

13000 

13000 

0 

0 

Total 

50 

50 

91000 

91000 

0 

0 

Data Group 

N/A 

50 

78000 

78000 

0 

0 

VoIP Group 

N/A 

50 

13000 

13000 

0 

0 

Total 

60 

60 

104000 

104000 

0 

0 

Data Group 

N/A 

60 

91000 

91000 

0 

0 

VoIP Group 

N/A 

60 

13000 

13000 

0 

0 

Total 

70 

70 

117000 

117000 

0 

0 

Data Group 

N/A 

70 

104000 

104000 

0 

0 

VoIP Group 

N/A 

70 

13000 

13000 

0 

0 

Total 

80 

80 

130000 

130000 

0 

0 

Data Group 

N/A 

80 

117000 

117000 

0 

0 

VoIP Group 

N/A 

80 

13000 

13000 

0 

0 

Total 

90 

90 

156000 

156000 

0 

0 

Data Group 

N/A 

90 

143000 

143000 

0 

0 

VoIP Group 

N/A 

90 

13000 

13000 

0 

0 

Total 

100 

100 

169000 

169000 

0 

0 

Data Group 

N/A 

100 

156000 

156000 

0 

0 

VoIP Group 

N/A 

100 

13000 

13000 

0 

0 


Table 36. MRV’S SMART BITS DATA AT RAYTHEON 


The exciting portion of this day’s testing was when both technologies 
(FSO and RFM) were integrated. Only MRV’s Terescope 5000 made this combination 
possible. The product and its capabilities are explained in the next section of testing. 
h. MRV-RFM Switchover 

The RFM was connected to the MRV manufactured media converter. 
This converted the CAT 5 Ethernet from the RFM to fiber to feed the Terescope 5000 
scope. The Terescope 5000 has two optical connections; one is for the direct liber feed 
and the other is the standby to another fiber or RF backup system. With the MRV patent 
Fusion feature, the auto switching from the FSO to RFM took place within 2 
milliseconds. Therefore, there was little to no impact in the traffic being transmitted. The 
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Terescope 5000 Fusion is a bit different than the Tereseope 3000 unit in that the auto 
switeh over from the FSO to the RFM was done internally in the Terescope 5000 scope. 
There was no external switch required for this action, which really simplified the 
installation. The figure below shows an illustration of the Terescope 5000 with the built- 
in OptiSwitch feature (Figure 42). 



Figure 43. MRV’S TERESCOPE 5000 WITH BUIET-IN OPTISWITCH 

During the switchover portion of the experiment, MRV’s Terescope was 
covered so that the REM could pick up the link between local area networks. Simulated 
computer and VoIP data was being sent across the network via SmartBits. The laser was 
covered while SmartsBits was running. This process forced the REM to pick up the link 
via the OptiSwitch. The table below is an excerpt of the SmartBits data collected while 
this experiment was in progress (Table 37). The packet loss was recorded at 50 percent 
due to the change between the ESO link and REM. 
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Total 

10 

10 

24000 

12000 

12000 

50 

Data Group 

N/A 

10 

16000 

8000 

8000 

50 

VoIP Group 

N/A 

10 

8000 

4000 

4000 

50 

Total 

20 

20 

40000 

20000 

20000 

50 

Data Group 

N/A 

20 

32000 

16000 

16000 

50 

VoIP Group 

N/A 

20 

8000 

4000 

4000 

50 

T otal 

30 

30 

56000 

28000 

28000 

50 

Data Group 

N/A 

30 

48000 

24000 

24000 

50 

VoIP Group 

N/A 

30 

8000 

4000 

4000 

50 

Total 

40 

40 

72000 

36000 

36000 

50 

Data Group 

N/A 

40 

64000 

32000 

32000 

50 

VoIP Group 

N/A 

40 

8000 

4000 

4000 

50 

Total 

50 

50 

88000 

44000 

44000 

50 

Data Group 

N/A 

50 

80000 

40000 

40000 

50 

VoIP Group 

N/A 

50 

8000 

4000 

4000 

50 

Total 

60 

60 

104000 

52000 

52000 

50 

Data Group 

N/A 

60 

96000 

48000 

48000 

50 

VoIP Group 

N/A 

60 

8000 

4000 

4000 

50 

T otal 

70 

70 

120000 

60000 

60000 

50 

Data Group 

N/A 

70 

112000 

56000 

56000 

50 

VoIP Group 

N/A 

70 

8000 

4000 

4000 

50 

Total 

80 

80 

136000 

68000 

68000 

50 

Data Group 

N/A 

80 

128000 

64000 

64000 

50 

VoIP Group 

N/A 

80 

8000 

4000 

4000 

50 

Total 

90 

90 

152000 

76000 

76000 

50 

Data Group 

N/A 

90 

144000 

72000 

72000 

50 

VoIP Group 

N/A 

90 

8000 

4000 

4000 

50 

Total 

100 

100 

168000 

84000 

84000 

50 

Data Group 

N/A 

100 

160000 

80000 

80000 

50 

VoIP Group 

N/A 

100 

8000 

4000 

4000 

50 


Table 37. MRV’S OPTISWITCH SMART BITS DATA AT RAYTHEON 


During the Smart Bits test, SolarWinds recorded a 54 Mbps throughput 
when the data was going across the FSO link and a 33 Mbps throughput when the data 
was going across the RFM link. Throughout the SmartBits testing, SolarWinds did not 
drop the link (the term “not drop the link” indicated that the link remained operational 
while the switchover occurred between media links). 

The last day of testing was very exciting; a new technology was 
introduced to the authors of this thesis. The new technology was Orthogonal Frequency 
Division Multiplexing (OFDM). Alvarion demonstrated their OFDM product, which has 
BFOS capability. Alvarion’s OFDM product is explained in the BFOS section of the 
Raytheon testing. Also on the last day of testing, the Iridium Inverse Multiplexer 
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(IMUX) was tested. The IMUX test can be found in the OTH section of the Raytheon 
testing. Another FSO company, ffiONA, was tested at the 6.7 kilometer range. 

u fSONA 

The company, tSONA, brought the same product, SONAbeam 155-M, as 
the previous testing evolutions. The personnel that tEONA sent to support the 
experiments were Mike Corcoran, Senior Vice President of Sales and Marketing; Kelly 
Irvin, Director Western Sales; Pablo Bandera, tSONA’s Product Manager; and Sean 
Dante, Field Technician. The equipment took roughly 45 minutes to set up and align. 
The series of testing included an Iperf data test, a data file transfer test monitored by 
SolarWinds, and a Smart Bits test. 

The Iperf test consisted of nine data runs. Six of the data runs were 
conducted with IBONA’s equipment uncovered (without any crypto, KG-235). The 
window size was manipulated in order to obtain the maximum throughput for the link 
being tested. Then, three data runs were conducted using the KG-235s for bulk 
encryption (results were discussed earlier in this thesis). The maximum throughput 
obtained without using the KG-235 is represented below. 


Server listening on TCP port 5001 
TCP window size: 0.1 MByte 


[920] local 192.168.3.3 port 5001 connected with 192.168.1.2 port 1038 

[ ID] Interval Transfer Bandwidth 

[920] 0.0-1.0 sec 10.9 MBytes 87.1 Mbits/sec 

[920] 1.0-2.0 sec 11.0 MBytes 88.1 Mbits/sec 

[920] 2.0-3.0 sec 11.3 MBytes 90.2 Mbits/sec 

[920] 3.0-4.0 sec 11.3 Mbytes 90.1 Mbits/sec 

[920] 4.0-5.0 sec 10.8 Mbytes 86.1 Mbits/sec 

[920] 5.0-6.0 sec 11.3 Mbytes 90.1 Mbits/sec 

[920] 6.0-7.0 sec 11.1 Mbytes 89.2 Mbits/sec 

[920] 7.0-8.0 sec 11.3 Mbytes 90.1 Mbits/sec 

[920] 8.0-9.0 sec 11.3 Mbytes 90.1 Mbits/sec 

[920] 9.0-10.0 sec 11.3 MBytes 90.1 Mbits/sec 

[920] 0.0-10.0 sec 112 MBytes 89.2 Mbits/sec 


The data transfer test monitored by SolarWinds consisted of 16 runs of 
data transfer. The first series of data transfer was conducted while VoIP was being used 
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across the link. The second series of data transfer was eondueted while VoIP was being 
used and a video camera also streamed video across the link. Additionally, each 




1 Run No. 

Media 

Size 

Time 

Throughput 

Loss (%) 

VOICE 

VIDEO 


1 

FSO 

1.5 M 

1" 

3.43M 

0 

YES 

NO 

2 

FSO 

5 M 

1" 

7.96M 

0 

YES 

NO 

3 

FSO 

10 M 

2" 

15M 

0 

YES 

NO 

4 

FSO 

75 M 

15" 

53M 

0 

YES 

NO 

5 

FSO 

150 M 

30" 

50M 

0 

YES 

NO 

6 

FSO 

300 M 

I'OO" 

45M 

0 

YES 

NO 

7 

FSO 

600 M 

2T0" 

50M 

0 

YES 

NO 

8 

FSO 

1.2 GIG 

4'26" 

45M 

0 

YES 

NO 


9 

FSO 

1.5 M 

1" 

2.91M 

0 

YES 

YES 

10 

FSO 

5 M 

1" 

8M 

0 

YES 

YES 

11 

FSO 

10 M 

2" 

16M 

0 

YES 

YES 

12 

FSO 

75 M 

12" 

45M 

0 

YES 

YES 

13 

FSO 

150 M 

30" 

52M 

0 

YES 

YES 

14 

FSO 

300 M 

52" 

52M 

0 

YES 

YES 

15 

FSO 

600 M 

2'20" 

50M 

0 

YES 

YES 

16 

FSO 

1.2 GIG 

5T5" 

36M 

0 

YES 

YES 


computer was running video on the eomputer as the test was being conducted. 


he table 


below indicates the data obtained while this test was eondueted (Table 38). 


Table 38. fSONA SOLARWINDS DATA AT RAYTHEON 


The next series of tests were conducted using SmartBits. During this 
series of testing, SmartBits simulated 100 eomputers passing data aeross the two 
networks and 24 simulated phone conversations passing information across the network. 
Out of all the technologies tested, ISONA had the lowest frame loss percentage. The 
frame loss percentage was .00118 %. This low frame loss percentage may be a result of 
ISONA’s lasers being able to produce a power output of 640 milliwatts, a eonsiderable 
differenee over all other companies. The network was stressed by applying data in 10 
Mbyte increments until the network was passing 100 Mbytes of data. The table below is 
an exeerpt of the data obtained by SolarWinds (Table 39). 
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Total 

10 

10 

26000 

26000 

0 

0 

Data Group 

N/A 

10 

13000 

13000 

0 

0 

VoIP Group 

N/A 

10 

13000 

13000 

0 

0 

Total 

20 

20 

39000 

39000 

0 

0 

Data Group 

N/A 

20 

26000 

26000 

0 

0 

VoIP Group 

N/A 

20 

13000 

13000 

0 

0 

Total 

30 

30 

52000 

52000 

0 

0 

Data Group 

N/A 

30 

39000 

39000 

0 

0 

VoIP Group 

N/A 

30 

13000 

13000 

0 

0 

Total 

40 

40 

65000 

65000 

0 

0 

Data Group 

N/A 

40 

52000 

52000 

0 

0 

VoIP Group 

N/A 

40 

13000 

13000 

0 

0 

Total 

50 

50 

91000 

91000 

0 

0 

Data Group 

N/A 

50 

78000 

78000 

0 

0 

VoIP Group 

N/A 

50 

13000 

13000 

0 

0 

Total 

60 

60 

104000 

104000 

0 

0 

Data Group 

N/A 

60 

91000 

91000 

0 

0 

VoIP Group 

N/A 

60 

13000 

13000 

0 

0 

Total 

70 

70 

117000 

117000 

0 

0 

Data Group 

N/A 

70 

104000 

104000 

0 

0 

VoIP Group 

N/A 

70 

13000 

13000 

0 

0 

Total 

80 

80 

130000 

130000 

0 

0 

Data Group 

N/A 

80 

117000 

117000 

0 

0 

VoIP Group 

N/A 

80 

13000 

13000 

0 

0 

Total 

90 

90 

156000 

156000 

0 

0 

Data Group 

N/A 

90 

143000 

143000 

0 

0 

VoIP Group 

N/A 

90 

13000 

13000 

0 

0 

Total 

100 

100 

169000 

168998 

2 

0.00118 

Data Group 

N/A 

100 

156000 

155998 

2 

0.00128 

VoIP Group 

N/A 

100 

13000 

13000 

0 

0 

able 39. 

fSONA’S SMARTS] 

[TS DATA AT 

EfAYTHEON 


The technologies used in the line-of-sight testing showed potential to be 
implemented in both a UOC and CAC2S architecture. A key tool used in determining the 
quality of the link across the network is the VoIP. The next section will briefly discuss 
VoIP. 

j. Voice Over Internet Protocol (VoIP) 

LT Manny Cordero has been studying VoIP at NPS. LT Cordero’s thesis 
involves VoIP and his contributions in providing a mixture of equipment and expertise 
was key to this thesis research. 

The IP telephones used were the Cisco 7960G. The telephones were 
connected to the network via CAT-5 cable to the Cisco switch. Present at the MRF was 
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the Call Manager server that managed the IP phones in the network. The server assigned 
eaeh phone its own IP address, whieh enabled any phone within the network to plaee a 
eall to any other phone in the network. 


In the following seetions VoIP was utilized with a BLOS eompany ealled 
Alvarion. While eondueting the data transfer test, SolarWinds would indieate the link 
being down. However, the VoIP phone eall was still operating aeross the link. The next 
section will discuss a Beyond line of Sight (BLOS) technology by Alvarion. 

1. Beyond Line-of-Sight (BLOS) 

Alvarion from Carlsbad, California, introduced a product that operated in a non- 
line-of-sight (NLOS) mode. Since the product operates in a NLOS mode, the BLOS 
problem was tested at a distance of 6,700 meters in order to demonstrate the capability. 

a. Alvarion 

The Alvarion personnel who supported this evolution were Director of 
Strategic Marketing, Jasper Bruinzeel, and field technicians Willie Alayza and Soria 
Constantino. The product introduced to the testing was Alvarion’s BreezeACCESS VL 
system. The system is a point-to-multi-point or point-to-point system. The system 
operates in the 5 GHz frequency band (5.725-5.850 GHz). The BreezeACCESS uses 
OEDM technology in order to overcome the BEOS problem. The product can operate in 
speeds of 6 Mbps, 24 Mbps, and 54 Mbps. The product used had an antenna and radio 
built into one unit. There are different versions of this product, so the antennas come in 
different sector types. The antennas can be directional or omni-directional. The type of 
equipment is determined by the application requirement the equipment needs to address. 

The testing data obtained resulted from an Iperf test and a SmartBits test. 
The Iperf test was conducted with and without the KG-235. Several runs were conducted 
in order to maximize the throughput across the link. In addition to adjusting the window 
size, the antenna was changed. The Iperf test started with a SU-VL integrated antenna 
with a lO-degree beam width and a 21 dB gain on the BreezeACCESS. While the Iperf 
test was being conducted, a VoIP call was made along with streaming video. There were 
three runs conducted with the SU-VE antenna. The maximum throughput results from 
the small antenna are indicated below. 
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Server listening on TCP port 5001 
TCP window size: 0.1 MByte 


[920] local 192.168.3.3 port 5001 connected with 192.168.1.2 port 1045 

[ ID] Interval Transfer Bandwidth 

[920] 0.0-1.3 sec 0.2 MBytes 1.3 Mbits/sec 

[920] 1.3-2.2 sec 0.2 MBytes 1.6 Mbits/sec 

[920] 2.2-3.5 sec 0.3 MBytes 1.6 Mbits/sec 

[920] 3.5-4.1 sec 0.3 MBytes 4.2 Mbits/sec 

[920] 4.1-5.1 sec 0.2 MBytes 1.7 Mbits/sec 

[920] 5.1-6.1 sec 0.3 MBytes 2.7 Mbits/sec 

[920] 6.1-7.1 sec 0.5 MBytes 3.9 Mbits/sec 

[920] 7.1-8.0 sec 0.4 MBytes 4.1 Mbits/sec 

[920] 8.0- 9.0 sec 0.9 MBytes 6.9 Mbits/sec 

[920] 9.0-10.0 sec 0.4 MBytes 3.0 Mbits/sec 

[920] 0.0-10.3 sec 3.8 MBytes 2.9 Mbits/sec 


A larger antenna, a two-foot Uni-directional antenna with a 28.5 dB gain 
and 3 dB beamwidth of 4.5 degrees, was attached to the BreezeACCESS. Two runs were 
conducted with the Uni-directional antenna while the streaming video camera and VoIP 
were operational in the background. The data below represents the maximum throughput 
data obtained from these runs. 


Server listening on TCP port 5001 
TCP window size: 0.1 MByte 


[920] local 192.168.3.3 port 5001 connected with 192.168.1.2 port 1050 

[ ID] Interval Transfer Bandwidth 

[920] 0.0-1.9 sec 0.0 MBytes 0.1 Mbits/sec 

[920] 1.9-2.0 sec 0.2 MBytes 9.0 Mbits/sec 

[920] 2.0-3.1 sec 0.7 MBytes 5.2 Mbits/sec 

[920] 3.1-4.1 sec 0.7 MBytes 5.4 Mbits/sec 

[920] 4.1-5.0 sec 0.4 MBytes 3.3 Mbits/sec 

[920] 5.0- 6.5 sec 0.5 MBytes 2.4 Mbits/sec 

[920] 6.5-7.0 sec 0.5 MBytes 9.1 Mbits/sec 

[920] 7.0- 8.0 sec 0.5 MBytes 3.6 Mbits/sec 

[920] 8.0- 9.3 sec 0.5 MBytes 2.8 Mbits/sec 

[920] 9.3-10.2 sec 0.3 MBytes 2.5 Mbits/sec 

[920] 0.0-10.2 sec 4.1 MBytes 3.2 Mbits/sec 
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The KG-235 was placed between the Breeze ACCESS equipment and the 
Cisco router. There were several runs conducted with the window size changed on each 
run. While the Iperf data tests were running, VoIP and streaming video was running in 
the background. The following Iperf data represents the maximum throughput data 
obtained with the KG-235s in the network. 


Server listening on TCP port 5001 
TCP window size; 0.1 MByte 


[920] local 192.168.1.25 

port 5001 connected with 192.168.3.25 port 1811 

[ ID] Interval 

Transfer 

Bandwidth 

[920] 0.0- 1.0 sec 

0.3 MBytes 

2.7 Mbits/sec 

[920] 1.0-2.1 sec 

0.2 MBytes 

1.8 Mbits/sec 

[920] 2.1-3.3 sec 

0.4 MBytes 

2.3 Mbits/sec 

[920] 3.3-4.0 sec 

0.3 MBytes 

3.1 Mbits/sec 

[920] 4.0-5.2 sec 

0.2 MBytes 

1.6 Mbits/sec 

[920] 5.2-6.1 sec 

0.2 MBytes 

1.9 Mbits/sec 

[920] 6.1-7.0 sec 

0.3 MBytes 

2.5 Mbits/sec 

[920] 7.0-8.0 sec 

0.4 MBytes 

2.9 Mbits/sec 

[920] 8.0-9.0 sec 

0.3 MBytes 

2.6 Mbits/sec 

[920] 9.0-10.0 sec 

0.3 MBytes 

2.7 Mbits/sec 

[920] 0.0-10.1 sec 

3.0 MBytes 

2.4 Mbits/sec 


The final test conducted with Alvarion was the SmartBits test. During the 
SmartBits test, 100 computers were simulated passing data across the network with data 
increments of 10 Mbytes until a maximum throughput of 30 Mbytes was reached. The 
table below represents an excerpt of the data obtained while conducting the SmartBits 
test (Table 40). 
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Total 

5 

5 

8126 

8126 

0 

0 

Data Group 

N/A 

5 

8126 

8126 

0 

0 

Total 

10 

10 

16254 

16253 

1 

0.00615 

Data Group 

N/A 

10 

16254 

16253 

1 

0.00615 

Total 

15 

15 

24382 

18840 

5542 

22.7299 

Data Group 

N/A 

15 

24382 

18840 

5542 

22.7299 

Total 

20 

20 

32508 

20813 

11695 

35.9758 

Data Group 

N/A 

20 

32508 

20813 

11695 

35.9758 

Total 

25 

25 

40636 

20709 

19927 

49.0378 

Data Group 

N/A 

25 

40636 

20709 

19927 

49.0378 

Total 

30 

30 

48764 

20600 

28164 

57.7557 

Data Group 

N/A 

30 

48764 

20600 

28164 

57.7557 


Table 40. ALVARION’S SMARTBITS DATA AT RAYTHEON 


Figure 43 indicates a frame size of 1,518 Kbytes and a throughput of 30 
Mbps on the left and a frame loss of 57.8% on the right. The reason for the large frame 
loss is that the throughput oversaturated the link and packets were lost during this state of 
exchange between the sites. 
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Throughput vs Frame Size 

Figure 44. ALVARION’S SMARTBITS GRAPH AT RAYTHEON 

The final experiment eondueted at Raytheon was the Iridium Inverse 
Multiplexer. This technology provided OTH connectivity and is explained in the 
following section. 

2, Over-the-Horizon (OTH) 
a. IMUX 

The IMUX, as described in earlier testing, is a product that gives the 
warfighter OTH capability on the battlefield. As described in the General Dynamics 
testing earlier in this thesis. Dr. Glenn Abousleman utilized his compression algorithm 
over the limited throughput Iridium satellite architecture. The data obtained from the 
IMUX was the Iperf test data. Carey Foushee, General Dynamics Decision Systems 
field engineer, was the engineer who made the IMUX operational. Several data runs 
were conducted with the IMUX. The excerpt below is an example of the Iperf data 
collected from the test. 
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Server listening on TCP port 5001 
TCP window size: 62.7 KByte 


[920] local 192.168.3.3 

port 5001 connected with 192.168.1.2 port 1050 

[ ID] Interval 

Transfer 

Bandwidth 

[920] 0.0-3.0 sec 

1.9 KBytes 

5.2 Kbits/sec 

[920] 3.0-5.5 sec 

1.9 KBytes 

6.1 Kbits/sec 

[920] 5.5-7.8 sec 

3.4 KBytes 

11.7 Kbits/sec 

[920] 7.8-9.0 sec 

1.0 KBytes 

6.5 Kbits/sec 

[920] 9.0-10.1 sec 

4.3 KBytes 

31.1 Kbits/sec 

[920] 10.1-11.5 sec 

4.3 KBytes 

24.1 Kbits/sec 

[920] 11.5-12.1 sec 

0.5 KBytes 

6.9 Kbits/sec 

[920] 12.1-14.3 sec 

3.4 KBytes 

12.5 Kbits/sec 

[920] 14.3-16.7 sec 

1.9 KBytes 

6.2 Kbits/sec 

[920] 16.7-18.8 sec 

1.2 KBytes 

4.6 Kbits/sec 

[920] 18.8-20.5 sec 

0.5 KBytes 

2.3 Kbits/sec 

[920] 20.5-21.3 sec 

0.7 KBytes 

7.2 Kbits/sec 

[920] 21.3-25.7 sec 

1.7 KBytes 

3.1 Kbits/sec 

[920] 25.7-27.9 sec 

1.2 KBytes 

4.4 Kbits/sec 

[920] 27.9-30.2 sec 

1.2 KBytes 

4.2 Kbits/sec 

[920] 30.2-32.6 sec 

1.2 KBytes 

4.0 Kbits/sec 

[920] 32.6-36.9 sec 

1.7 KBytes 

3.1 Kbits/sec 

[920] 36.9-38.7 sec 

0.5 KBytes 

2.2 Kbits/sec 

[920] 38.7-39.1 sec 

0.7 KBytes 

12.8 Kbits/sec 

[920] 39.1-41.4 sec 

1.2 KBytes 

4.2 Kbits/sec 


The testing interval was extended up to 112 seeonds for eaeh of these runs. 
The average throughput observed was 9.6 Kbps during the runs. The compression 
algorithm observed in the Mobile Research Facility showed that a several Mbyte picture 
was compressed and sent over the Iridium link within seconds. This would have taken 
close to an hour without the compression algorithm applied. 

The following section will discuss the KG-235 In-Line Network Encryptor 
(INE). The INE was used with the IMUX and the results were on average 9.6 Kbps of 
throughput across the link. Additionally, the KG-235 bulk encryption was tested 
throughout the experiment with different technologies. 

b. Crypto (INE) 

GDDS provided two KG-235 Sectera INE and field engineer, Carey 
Eoushee made them operational. The manufacturer of this product is GDDS. The 


104 





purpose of utilizing these deviees was to secure the link between the two local area 
networks and to observe any noticeable difference in the throughput while applying 
encryption. When using the INE with the IMUX, 9.6 Kbps was observed as an average 
throughput. Throughout the week, Mr. Foushee diligently established the link between 
the two networks. The line of sight companies tested with the INE were Terabeam and 
ISONA. Their results were discussed earlier in this thesis. The results from the BEOS 
company tested, Alvarion, can be found in the Alvarion section of this thesis. 

The testing at Raytheon proved to be interesting and educational. In 
March, a combination of all these technologies was integrated at Camp Roberts, 
California. 

D, FIELD TEST #4 (CAMP ROBERTS) 

From March 7-11, 2004 at Camp Roberts, CA, seven NFS students, four Marines 
from Marine Air Support Squadron 6 out of Miramar Air Station, and several vendors 
participated in communications testing which emulated a Marine Corps tactical 
environment. The student participants from NFS were Captain Gilbert Garcia, Captain 
David Joseforsky, FT Manny Cordero, FT Albert Seeman, FT Ryan Blazevich (USN), 
Captain Ray Munoz (USMC), and Captain Rob Guice (USMC). 

Fine-of-sight (EOS), beyond-line-of-sight (BEOS), and over-the-horizon (OTH) 
communications were set up and tested while at Camp Roberts for the following 
scenarios: Command and Control On-the-Move Network Digital Over-the-Horizon 
Relay (CoNDOR), communications on-the-move, and airborne relay. First, the 
CoNDOR scenario was set up with two remote sites located within EOS of a Foint of 
Fresence (FOF) site. This occurred with FSO equipment provided by Fightpointe and 
Terabeam. In addition, the two sites were moved BEOS from the FOF in order to use an 
Orthogonal Frequency Division Multiplexing (OFDM) product provided by Alvarion and 
Redline Communications. The remote sites to the FOF simulated a company-battalion 
relationship. The FOF site was furnished with a high throughput satellite link that 
communicated back to the Network Operations Center (NOC), which resembled a 
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battalion-regiment relationship. Segovia provided the satellite serviee and the satellite 
dishes were furnished by Omega Systems. 

Seeond, two vehieles, Mobile Radio Component (MRC) #1 and MRC #2, 
simulated a eonvoy driving through the training area whieh formulated the 
eommunieations on-the-move setup. This was done with the vehieles BLOS of eaeh 
other, so they eommunieated via OFDM equipment from Alvarion and Redline 
Communieations. One vehiele in the eonvoy, MRC #1, also had an INMARSAT satellite 
link on the final day of the exereise, whieh was operated separate from the established 
network. An 802.1 lb link was established between the lead eonvoy vehiele and the POP 
site via a tethered balloon. This enabled all vehieles in that eonvoy to eommunieate with 
the POP site. In addition, eaeh vehiele in the eonvoy had its own wireless LAN via an 
802.1 la Aeeess Point. 

Lastly, the authors employed a tethered balloon and Unmanned Aerial Vehiele 
(UAV) over the training area as a means to extend the network. They did this by 
employing 802.11b omni-direetional antennas at eaeh site: MRC #1, POP, NOC, and on 
the airborne platforms. The tethered balloon retransmitted 802.11b signals between the 
lead vehiele in the eonvoy and the POP site. MLB Company’s UAV platform was 
employed as an airborne relay as well, but it was not employed within the network. 

The original intent was to use the Ciseo Mobile Aeeess Router (MAR), a hand 
sized router made up of a staek of different eards, at eaeh of the ground nodes as a deviee 
that eould aeeept multiple teehnologies at the same time from multiple sites. For 
example, if at the POP three different types of teehnologies were eoming in and a LAN 
was required, then four Ethernet ports that were layer 3 eapable would be needed. Sinee 
the regular Ciseo routers available for this testing event only had two layer 3 Ethernet 
ports available on eaeh deviee, one router eould not aeeomplish the task. In addition, the 
students intended to test the MARs in the airborne platforms by eonneeting two different 
types of teehnologies to the MAR at the same time. If the MAR sensed that the primary 
means of transmission degraded, then it would automatieally switeh to the seeondary 
means. Eigure 44 below shows the MAR. 
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Figure 45. MOBILE ACCESS ROUTER48 

Unfortunately, after days of working on the MAR’s eonfigurations, the students 
and the eommereial eompany on-hand to assist, Western DataCom, eould not get these 
deviees to funetion properly. Sinee the MARs were not operational, the students deeided 
to use the Ciseo 3745 and 2600 series routers in a variety of ways: eonneeting two 
routers together, inserting a switeh between the routers, and utilizing the Ciseo 3550 
Switeh as a layer 3 deviee to route. 

In order to bring all the above seenarios together by the end of the week, the 
students eondueted the testing in a step-by-step fashion where eaeh seenario was tested 
individually. On 8 Mareh, three nodes were used: NOC, POP, and MRC #1. The NOC 
and POP were separated by about 2 kilometers and a hill. Thus, the two sites maintained 
eommunieation via an OEDM link in non-line-of-sight mode. At the POP, a Ciseo 2950 
Switeh was plaeed between the two Ciseo routers in order to faeilitate OEDM and ESO 
links, as well as a LAN. This was done beeause eaeh router had only two Ethernet ports 
that were layer 3 eapable, and the switeh was a layer 2 deviee. Next, the students 
established a EOS situation between the POP and MRC #1 at about 1,000 meters. The 
eonneetivity between the two sites was established with an ESO link. Einally, in order to 
faeilitate eoordination between all sites, single-ehannel voiee eommunieations were 
attained via VHF and HF manpaek radios. The VHF net was on a PRC-119 radio that 
was remoted into the EAN area with an A/N GRA-39. The NOC was equipped with an 
OE-254 long range VHF antenna, while the other two sites used 10-foot whip antennas. 
In addition to the VHF net, an A/N PRC-104 provided redundant eommunieations on an 
HF net. Figure 45 below illustrates the setup. 


48 http://www.cisco.cotn/en/US/products/hw/routers/ps272 (May 2004). 
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Figure 46. 8 MARCH COMMUNICATIONS ARCHITECTURE 


On 9 March, several additions and changes were made to the communications 
architecture. First, MRC site #2 was added in order to facilitate two nodes 
communicating with the POP site. MRC #I was EOS with the POP using an ESO link at 
about 1,000 meters, and MRC #2 was BEOS with the POP using OEDM technology also 
at about 1,000 meters. The POP was now connected with the NOC via a broadband 
satellite link. 

At the POP site, a Cisco 3550 Switch replaced the router-switch combination. 
This facilitated one device being able to handle three different technologies at the same 
time, such as FSO, OEDM, and broadband satellite, and also a EAN. The 3550 Switch is 


108 


































































a Layer 2/3 capable device, which means that it is capable of routing traffic. 
Unfortunately, the students were unable to program a routing protocol into the switch. 
Thus, the switch could not automatically establish a routing table to talk with the other 
wide area network routers, which were using Enhanced Interior Gateway Routing 
Protocol (EIGRP). Ross Warren from Segovia and ET Cordero had to manually input all 
the routes into the routers and Cisco 3550 Switch so the devices would know where to 
find each other. 

Einally, single-channel voice communications were again established with the 
PRC-119s and PRC-104s. These were vital assets as coordination took place to get each 
of the links established and to conduct the days test. The tethered balloon was also 
employed on this day as a means of communication between the NOC and the POP sites. 
The tethered balloon and the satellite link were not redundant communications, but they 
were employed separately on the network. In order to do this, the students unplugged the 
satellite link from the network and plugged the 802.11b link into the same ports that the 
satellite was hooked into. Eigure 46 below gives further detail of this day’s setup. 
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Figure 47. 9 MARCH COMMUNICATIONS ARCHITECTURE 


The next day of testing, 10 March, was the first attempt to incorporate all 
scenarios mentioned above. Communications on-the-move was performed by MRC #I 
and #2, as both vehicles had their own LAN setup in the vehicles. The objective of the 
experiments with these vehicles was to simulate a convoy where the vehicles did not have 
LOS communications. Thus, the two vehicles drove BEOS of each other and OEDM 
technology was utilized to keep the vehicles in contact with each other. Next, ESO was 
employed in MRC #1 and #2 when the vehicles planned to stop and attain LOS with one 
another. The OEDM link and ESO were not used simultaneously, but were rather used 
separate from each other. 

The lead vehicle, MRC #1, was also equipped with an omni-directional antenna to 
establish communication with the POP through the tethered balloon with 802.11b. The 
same setup was employed at the POP and NOC as the previous day with the Cisco 3550 
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Switch at the POP and the broadband satellite equipment conneeting the two sites. The 
addition on this day was integration of an UAV into the setup. This platform was 
employed off of the network at various times throughout the day in order to test the 
reliability of its eommunieations relay. The UAV and tethered balloon were used as 
aerial relay platforms of 802.1 lb. 


Finally, VHF voiee eommunieations were used throughout the day. This greatly 
assisted all the nodes to communieate while the vehicles were in motion. Figure 47 
below portrays the arehiteeture on this day. 



Figure 48. 10 MARCH COMMUNICATIONS ARCHITECTURE 


On II Mareh, except for one change at MRC #I and the addition of the 

INMARSAT, the eommunieations architecture was the same as the previous day. MRC 

#I and #2 were still eondueting eommunieations on-the-move, along with statie 

conneetivity using FSO. At MRC #1, based on the previous day’s lessons learned, the 

students deeided to plaee the Ciseo 2950 switeh between the two routers in order to 
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facilitate the connections of 802.1 lb, OFDM/FSO, and a LAN. During the previous day, 
an attempt was made to install a module on the Ciseo 3745 router that had multiple IP 
ports. Unfortunately, the ports on the module were unable to perform layer 3 eapabilities, 
so the students had to employ a method that was used at the POP on the first day of 
testing. This assisted in getting the LAN established at MRC #1. 

The INMARSAT link was utilized at MRC #1, but communications were never 
established with the network. Instead of using it as originally intended in place of the 
tethered balloon, the students used the INMARSAT serviee to search the Internet and 
make test phone calls while on the move in MRC #1. A phone was placed at MRC #1 
and at the NOC to test the phone conneetivity. 


Onee again single-ehannel voice eommunieations were utilized between all the 
nodes to facilitate planning and coordination. Figure 48 below displays the architeeture 
on this day. 
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The ultimate goal of this testing event was to determine which of the technologies 
evaluated proved useful while employed during the above scenarios. In addition, the 
authors evaluated how the technologies reacted to one another when merged together 
throughout the WAN’s communications architecture. The focus was not on data 
collection of throughput rates as in previous field tests. The following state-of-the-art 
wireless technologies were tested: Free Space Optics, 802.11b, 802.11a, OFDM, 
INMARSAT, and Broadband Satellite. Voice over Internet Protocol (VoIP) was 
implemented in the local area networks to test the quality of service over this multitude of 
technologies. 

1, Line-of-Sight (LOS) 
a. Lightpointe 

Lightpointe supported the testing evolution from March 7-9 with Jim 
McGowan, Sales Director, and Albert Borquez, Network Engineer. They brought their 
FlightStrata OC-3 FSO Fly Away Package, which included two link heads for end-to-end 
connectivity. Lightpointe’s personnel arrived on 7 March in order to assist in the 
baseline testing being conducted. They set up a short 50-meter link on this day. Due to 
the FlightStrata’s Auto Power Control, the short distance was easily accomplished. They 
were configured similarly to the Raytheon testing event where they ran a multi-mode 
fiber cable from the link head to a media converter and then from the converter to the 
network router via CAT-5 cable. The main focus of this day’s experiments was to ensure 
the network equipment was working appropriately before gear and personnel moved to 
the training area the next day. 

On 8 March, Lightpointe established one link at MRC #1 and the other at 
the POP site. The purpose of this day’s experiments was to establish connectivity from 
the NOC to the POP via OFDM and from the POP to MRC #1 through FSO. The 
distance between MRC #1 to the POP was about 1,000 meters. Terabeam was setup at 
MRC #1 as well on this day. The authors managed to switch the links of both companies 
in and out of the network, so they did not operate simultaneously. Figure 49 shows the 
setup of the links at MRC #1. 
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Figure 50. LIGHTPOINTE AND TERABEAM SETUP AT MRC #1 ON 8 MARCH 


When going from the NOC to the POP via OFDM then to the MRC #1 site 
via Lightpointe’s FSO link, two tests were conducted using Iperf on 8 March. A sample 
set of data from this experiment can be found in Figure 50 below. 


Client connecting to 192.168.70.5, TCP port 5001 
TCP window size: 63.0 KByte (default) 


[928] local 192.168.20.3 port 1420 connected with 192.168.70.5 port 5001 


[ ID] Interval 
[928] 0.0-5.2 sec 
[928] 5.2-10.1 sec 
[928] 10.1-15.0 sec 
[928] 15.0-20.0 sec 


Transfer 

2.7 MBytes 

1.8 MBytes 

3.9 MBytes 
3.4 MBytes 


Bandwidth 
4.1 Mbits/sec 

2.9 Mbits/sec 

6.3 Mbits/sec 

5.4 Mbits/sec 


[928] 0.0-20.3 sec 11.7 MBytes 4.6 Mbits/sec 


Figure 51. IPERF DATA FROM NOC TO MRC #1 ON 8 MARCH 
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While these data rates are very low for an FSO link, the bandwidth was 
actually dictated by the OFDM link that was being used from the NOC to the POP, which 
was BLOS. See the Findings and Analysis section for further explanation. 

On 9 March, Lightpointe set up their link at MRC site #1 once again with 
Terabeam. MRC site #2 was set up with an OFDM link between the site and the POP, 
and the POP was connected to the NOC via Segovia/Omega Systems satellite link. That 
way, the NOC was communicating through the satellite to the POP and from there to 
MRC #1 via FSO. Although the links were successfully established, the authors were 
unable to ping between the NOC and MRC #1 on this day due to routing issues on the 
Cisco 3550 switch at the POP. 

Overall, Lightpointe was able to display the diversity of their Fly Away 
package while maneuvering around the training area. Their personnel and product 
support was top notch during this testing evolution. 

b. Terabeam 

Terabeam supported this evolution with Craig Campadore, Sales, and 
Wayne Bailey, Engineer, from March 7-9. They brought Terabeam’s outdoor Elliptica 
OC-3 ESO product with them. The personnel from Terabeam arrived on 7 March to 
assist the students with baseline testing prior to deploying to the training area. The 
Elliptica link was setup at roughly 200 meters end-to-end, and a media converter was 
input between the link head and the network router. Multi-mode fiber cable was used 
from the link head to the media converter. Since the main focus of the baseline testing 
was to get network equipment operating properly, the Terabeam link was not tested for 
throughput ratings, but the link did perform flawlessly on this day. 

On 8 March, Terabeam’s personnel departed for the training area to set up 
one link at the POP and the other at MRC #1. The goal on this day was to establish 
connectivity between the NOC, POP, and MRC #1. The NOC to POP communications 
was via OEDM, and the POP to MRC #1 was via ESO. The data that was collected was 
very similar to what Eightpointe experienced. The OEDM link dictated the throughput 
from the NOC to MRC #1. Since the throughput of the OEDM was anywhere between 2- 
12 Mbps while established in the network, the ESO link pushed through what was 
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coming in. Thus, the overall throughput data obtained from the NOC to MRC #1 is 
reported in Figure 51 below. This data was eolleeted in Iperf 


Client connecting to 192.168.70.5, TCP port 5001 
TCP window size: 63.0 KByte (default) 


[928] local 192.168.20.3 port 1420 connected with 192.168.70.5 port 5001 

[ ID] Interval Transfer Bandwidth 

[928] 0.0- 5.2 sec 2.7 MBytes 4.1 Mbits/sec 

[928] 5.2-10.1 sec 1.8 MBytes 2.9 Mbits/sec 

[928] 10.1-15.0 sec 3.9 MBytes 6.3 Mbits/sec 

[928] 15.0-20.0 sec 3.4 MBytes 5.4 Mbits/sec 

[928] 0.0-20.3 sec 11.7 MBytes 4.6 Mbits/sec 


Figure 52. IPERF DATA FROM NOC TO MRC #1 VIA OFDM AND FSO 


Terabeam was set up at MRC #I on 9 Mareh as well. MRC site #2 was 
established on this date with an OFDM link eonneeting the site to the POP. The satellite 
link provided by the Segovia/Omega Systems team was intereonnecting the NOC and 
POP site. Thus, on this day three different technologies were established in the Wide 
Area Network. Unfortunately, due to routing problems on the Ciseo 3550 switeh at the 
POP site, no data eould be transferred to the MRC site #1. 

Terabeam’s support was superb throughout their three days of testing at 
Camp Roberts. They were able to deploy their gear throughout the training area and 
establish eonneetivity in an expedient manner. 

c. fSONA 

fSONA responded to a short notiee request to support this testing event 
with their FSO teehnology. Pablo Bandera, Produet Manager, eame out from British 
Columbia, Canada with IBONA’s SONAbeam 155-E ESO produet that supports El to 
OC-3, rate-adaptive. The SONAbeam 155-E is a lightweight unit that is optimized for 
short-distance links from 50 meters up to 2,500 meters. It ineludes two redundant high- 
powered lasers transmitting at 1550 nanometers.49 During this testing event, the 155-E 

49 http://www.fsona.cotn/product.php?sec=155e (April 2004). 
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sat on top of a lightweight telescopic stand. It used a single-mode fiber cable from the 
link head to the media converter, and then from the media converter to the network 
router via a CAT-5 cable. Figure 52 shows the SONAbeam 155-E. 



Figure 53. fSONA’s SONABEAM 155-E50 

fSONA was integrated into the testing on March 10-11 during the 
communications on-the-move portion. The authors arranged to use Redline and 
Alvarion’s OFDM link between the two vehicles in the convoy while in motion. To 
incorporate IBONA’s equipment, each vehicle, MRC #1 and MRC #2, was equipped with 
a SONAbeam 155-E. After a certain amount of testing was done with OEDM, the 
vehicles stopped on the side of the road and attained EOS for the ESO link. This 
established a link between the two vehicles at about 500 meters. The goal on both days 
with lEONA was to use Segovia/Omega Systems’ satellite link between the NOC and 
POP, the 802.11b signal between the POP and MRC #1 thru the tethered balloon, and 
finally the ESO link between MRC #1 and MRC #2. 

Mr. Bandera set up the two links within 25 minutes, but then ran into 
trouble when connecting to the media converters. When connecting the single-mode 
fiber cable to the media converters, the converters did not show a link light. This 
happened on both days, so the goal of establishing connectivity with ESO between MRC 
#1 and #2 was not accomplished. See the bindings and Analysis section for further 
explanation. 


50 http://www.fsona.cotn/product.php?sec=155e (May 2004). 
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d. 802.11a (Vehicles) 

On several occasions at different sites and times, the Wireless Access 
Point (WAP) 55AG was used to provide a 802.11a Wireless LAN (WLAN). The 
computers in the WLAN were equipped with WPC55AG notebook adaptors to 
communicate with the access point. 

The WAP55AG actually contains two separate wireless connectivity 
radio transceivers, which support 802.1 la/b/g popular wireless networking specifications. 
The first transceiver uses the 2.4 GHz radio band, supporting both the widely used and 
inexpensive Wireless-B (802.11b) standard at 11 Mbps, and the new, almost five times 
faster, Wireless-G (draft 802.1 Ig) at 54 Mbps. The second radio operates in the 5 GHz 
band, and supports Wireless-A (802.11a) networking, also at 54 Mbps. Since the two 
radios operate in different bands, they can work simultaneously, blanketing a wireless 
zone with high-speed bandwidth.51 

e. Voice Over Internet Protocol (VoIP) 

A mixture of Cisco 7940G, 7960G, and 7920 IP telephones were used to 
provide voice service throughout the network. The 7940G and 7960G phones use a 
simple CAT-5 cable connection, while the other end was connected to the LAN Cisco 
switch. The Cisco Wireless IP Phone 7920 is an easy-to-use IEEE 802.1 Ib wireless IP 
phone that provided comprehensive voice communications in conjunction with Cisco’s 
Call Manager product. At the NOC, the wireless 7920 IP telephone was utilized with a 
Einksys 802.1 lb access point attached to the LAN switch. The Call Manager server was 
always located at the NOC. The phones throughout the two LANs first talked to the 
server before making a call to another phone within the network. The server was 
connected to the NOC Cisco 2950 switch via CAT-5 cable. Each phone and the server 
was assigned its own unique IP address. Einally, each phone had a phone number 
assigned to it by the server. This enabled a quick call to any phone on the network. 

The Voice over IP protocol employed was Cisco’s Call Manager Skinny 
Client Control Protocol (SCCP). SCCP is a Cisco proprietary protocol used between 
Cisco Call Manager and Cisco Voice over IP phones. This protocol is also supported by 
other vendors. The Cisco IP Phones 7960G and 7940G are also capable of supporting 


51 http://www.linksvs.cotn/t:)roducts/product.asp?grid=33&scid=35&prid=538 (May 2004). 
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other protocols such as Session Initiated Protocol (SIP), and Media Gateway Control 
Protocol (MGCP). However, the students chose to use the SCCP. 

Finally, the link between the NOC and POP saw no quality of service 
issues with VoIP, even while traversing a satellite link that was double hopping from the 
NOC to the POP. There was a slight delay when talking but the clarity of voices was 
nearly perfect. Even when communicating from the NOC to the POP via satellite link 
and then to MRC #1 and #2 sites via FSO or OFDM, the quality of service was not 
affected. Testing was not conducted evaluating VoIP when the vehicles were on the 
move. 

2, Beyond Line-of-Sight (BLOS) 
a. Alvarion 

Alvarion supported this testing event from March 8-11 with Soria 
Constantino, Field Technician, from Carlsbad, CA. Mr. Constantino brought with him 
Alvarion’s BreezeACCESS VF system. This system offers non-line-of-sight (NFOS) 
point-to-multipoint or point-to-point solutions in the 5 GHz band 5.725-5.850 GHz and 
5.47-5.725 GHz. The BreezeACCESS uses OFDM technology to overcome obstacles, 
such as trees, buildings, and hills for quick and effortless NFOS deployments. It can 
operate at speeds of 6 Mbps, 24 Mbps, and 54 Mbps. The system comes with indoor and 
outdoor units. The indoor unit is a lightweight, handheld device that is powered by 
110V/220V AC. It has an RJ-45 port to run CAT-5 cable from the unit to a network 
device, such as a router for this testing event. 52 This unit is shown in Figure 53 below. 



Figure 54. BREEZEACCESS VF INDOOR UNIT53 


52 http://www.alvarion.com/RunTime/Products 2Q2Q.asp?tNodeParam=3Q (April 2004). 

53 Alvarion, “Broadband Wireless Access Brief’, February 2004. 
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The outdoor unit consists of an antenna and radio, which is built into the 
antenna. The antenna can produce sector, omni-directional, or tight beam radiation 
patterns. There is an RJ-45 port on the outdoor unit as well, which connects to the indoor 
unit via a CAT-5 cable. This unit is depicted in Figure 54 below. 



Figure 55. BREEZEACCESS VL OUTDOOR UNIT54 

During the testing event on 8 March, Alvarion set up a point-to-point link 
at Camp Roberts between the NOC and POP sites. This setup was BEOS over a hill that 
was roughly 100-200 feet tall with trees sporadically located between the links. At the 
NOC site, the antenna was set on a mast that was raised to about 20 feet high. At the 
POP site, the antenna was also on a similar mast of 20 feet. Both of these antennas were 
two-foot uni-directional antennas with a 28.5 dBi gain and 3 dB beamwidth of 4.5 
degrees. The data collected going from the NOC to the POP via Alvarion’s link showed 
that 12 Mbps of data was being transferred when using Iperf (64 Kbyte size packets). 
When going from the NOC to the POP over Alvarion’s link and then from the POP to 
MRC #1, where an ESO link was established, the data from Iperf (64 Kbyte size packets) 
showed 5.4 Mbps of throughput. Alvarion also had a program called Q-Check that ran 
throughput tests over the link. Q-Check is a network troubleshooting utility that checks 
network response time, throughput, and streaming performance.55 This throughput data 
ranged between 4-12 Mbps when going from a computer on the EAN at the NOC site to 
a computer on the LAN at the POP site. The setup time during this day was about one 

54 Alvarion, “Broadband Wireless Aeeess Brief’, February 2004. 

55 http://www.ixiaeom.eom/produets/performanee applieations/pa displav.php?skev=pa q eheek 
(May 2004). 
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hour for the Alvarion link between the NOC and POP sites, but Mr. Constantino was 
working alone so he had to go baek and forth between the two sites. 


On 9 Mareh, Alvarion deployed out to the MRC #2 and POP sites with the 
same equipment as the previous day. The 1,000-meter link was set up BLOS, and the 
terrain between the sites was hilly with numerous trees throughout the landseape. Sinee 
the foeus was on establishing the network with the Ciseo 3550 Switeh at the POP site, the 
researehers did not oolleet data during this day. Although it took most of the day to 
establish a eonneetion, by 1700 eonneetivity from MRC #2 over the OFDM link was 
solid to the POP and NOC; however, eonneetivity to MRC #1 was not established due to 
routing eonfiguration issues at the POP switeh. 

Overall, Alvarion’s equipment and support were solid throughout the 
week. The biggest eonsideration when using the BreezeACCESS VL is the type of 
antenna sinee there are numerous seetor antennas as well as omni-direetional ones. A 
user must evaluate the seenario to determine what type of antenna to utilize. 

b. Redline Communications 

This testing event was the first time the students were able to work with 
Redline Communieations. Dave Rumore, Sales Representative, and Don Mullin, 
Engineer, supported this event from Mareh 8-10. They brought with them their AN-50 
OEDM system with seetor, narrow beam point-to-point and omni-direetional antennas. 
The AN-50 system operates in the lieense-exempt 5.8 GHz band and ineludes advaneed 
teehnologies to address potential inter-eell interferenee issues. The AN-50 maximizes 
speetral effieieney with a unique patented bi-direetional adaptive modulation teehnique, 
automatieally seleeting any of eight modulation sehemes providing a solid eonneetion 
even in ehallenging link eonditions. Eurthermore, the AN-50 delivers an over-the-air rate 
of up to 72 Mbps, a robust NLOS eapability, and audible antenna alignment and 
diagnostie eapabilities.56 

The essenee of OEDM is that it breaks up the transmitted signal into 
many smaller signals, as shown in Eigure 55 below. 


56 Redline Communications, “Redline Family White Paper”, October 2003. 
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Figure 56. OFDM CARRIER BREAKDOWN57 


Eor example, instead of one signal earrying 72 Mbps of data, there are 48 separate 
earners, eaeh earrying about 1.5 Mbps of data (in the ease of the Redline product). 

One key aspect of OEDM implementation is that the individual carriers 
overlap significantly to preserve overall bandwidth. Normally, overlapping signals 
would interfere with each other, however, through special signal processing, the carriers 
in an OFDM waveform are spaced in such a manner that they effectively do not see each 
other, i.e. they are orthogonal to each other.58 

On 8 March, Redline set up one of their sector antennas at the NOC and 
the other sector antenna was placed at the POP site. A distance of 2,000 meters with a 
hill and sporadic trees in between separated these two sites. The set up of the link took 
much longer than normal due to the lack of a good azimuth between the two sites. When 
Redline moved from the NOC to the POP, they had a rough estimate of what the azimuth 
would be but this proved insufficient. After an hour, Don Mullin returned to the NOC 
from the POP and determined that the antenna at the NOC site was way off from where 
the POP site was set up. After arranging the antenna in the appropriate direction, 
connectivity came up right away. Once the links were configured for the network, 
Redline used their computers and connected them to the LAN switches at both sites. 
They ran their Q-Check program, which was the same utility used by Alvarion, and it 
produced a reading between 5-11 Mbps from one computer to the other while varying the 

size of the packets. Iperf then sent 64 Kbyte size packets resulting in 2.4 Mbps from 

57 Redline Communications, “Second Generation High-Capacity Broadband Wireless Solutions”, 
April 2003. 

58 Redline Communications, “Second Generation High-Capacity Broadband Wireless Solutions”, 
April 2003. 
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computer to computer. After a while, Redline took their computers off of the LAN and 
hooked them directly onto the links resulting in a reading on Q-Check of 27 Mbps. Most 
of the data readings varied depending on the size of the packet being pushed across the 
link and where the computer was connected. 

One observation on 8 March was that Redline’s AN-50 system was set for 
auto-negotiation. Nothing was done on this day to change the setting to full duplex, and 
all of the network equipment was set for full duplex. This could have been another 
reason why the readings were inconsistent. Figure 56 below shows the AN-50 system. 



Figure 57. AN-50 SYSTEM 

On 9 March, Redline brought their equipment out to MRC #2 and the 
POP. They used the same equipment as the day before with their sector antennas 
mounted on five-foot stands. On this day, the terrain was less conducive to establish 
coimectivity with about 1,000 meters between the sites, due to more hills and dense tree 
lines. This was a good test to see if their equipment could perform as advertised. Once 
the equipment was aligned and set up, the link was established right away. Preparation 
was made ahead of time to get a good azimuth. An advantage of Redline’s AN-50 
system is that it has an audio tone that indicates link alignment. This greatly assists those 
who are establishing the link. Figure 57 below shows the terrain Redline had to traverse 
on this day. The data collected on 9 March from Q-Check was showing between 18-24 
Mbps when going from link to link and about 14 Mbps when running it on the LAN. The 
throughput drop was due to the networking equipment (laptops, switches, and routers). 
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Figure 5 8. REDLINE ’ S ANTENNA ON 9 MARCH AT MRC #2 

While experimenting on this day with the auto-negotiation on the AN-50 
system, the students determined that the system would go to full duplex if a switch was 
placed in between the AN-50 system and the EAN router. Thus, the hookup went from 
the sector antenna to the AN-50 via RE cable, then from the AN-50 to the switch via 
CAT-5, and from the switch to the router also via CAT-5. The link also proved to be 
more stable on this day. 

Overall, Redline Communications’ AN-50 products performed very well. 
They were invited by two Naval Postgraduate School professors to conduct further 
testing with NPS. These tests are at Camp Roberts, CA and are supported by Special 
Operations Command. 

c. Balloon 802.11 

The tethered balloon is approximately 12 feet in diameter when filled with 
helium. Several ta nk s of helium are needed for operation of the balloon, and it takes 
roughly an hour to completely fill the balloon. While airborne, the balloon does not 
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perform well in high winds. If winds are over 20 mph, the balloon should not be flown to 
alleviate possible damage. In addition, due to the eonstant movement of the balloon in 
high winds, steady connectivity can be challenging. 

The balloon can carry a payload of up to 50 pounds, which is located 
underneath the balloon. For the March testing, the payload was about 20 pounds and 
contained an omni-directional antenna, access point, 1-Watt Amplifier, DC to AC power 
converter, and two Lithium batteries used as the power source. A research associate at 
NFS, Kevin Jones, built this payload. Figure 58 below shows the actual payload with the 
access point and antenna located on the bottom and one lithium battery located on each 
side. 



Figure 59. TETHERED BAEEOON PAYLOAD 

To deploy or retrieve the balloon, an attached motor controls a large reel 
of rope. The balloon could reach an altitude of approximately 3,000 feet. To fly the 
balloon, a large open area is needed because high winds can cause the balloon to be 
pushed in a horizontally rather than vertically. Eigure 59 below shows the balloon 
system deployment/retrieval mechanism. 
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Figure 60. BASE OF THE TETHERED BAELOON 


On 8 March, the tethered balloon was first launched to conduct 
connectivity tests that were separate from the established network. The balloon was 
deployed to about 800 feet and the wind was relatively calm. 

The balloon’s access point was a Linksys WAPl 1. This device was set to 
run in bridge mode. On this day, another WAP 11 on the ground was used in bridge 
mode. The WAPl 1 has a web interface to configure the device. Entering the IP address 
of the access point into the URL line on Internet Explorer can access the web interface. 
Before doing this, the computer that is connected to the access point via CAT-5 cable 
must be on the same subnet as the IP address assigned to the access point. For example, 
if the IP address for the access point is 192.168.2.150, then the IP address for the 
computer configuring the access point must be I92.I68.2.X. In addition, after the IP 
addresses are set, the Media Access Control (MAC) address from the other access point 
must be entered for the access point that is being configured. Furthermore, the gateway 
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must be set to the IP address of the other aeeess point. This had to be done for eaeh 
access point on the ground as well as in the air. Figure 60 below gives an example of the 
Linksys web interface configuration page. 



Figure 61. WAP 11 WEB INTERFACE CONEIGURATION HOMEPAGE 


Overall, the initial test conducted on this day was point-to-point with both 
access points configured in bridge mode. The access point on the ground utilized the 
regular antennas that come with the device, and the access point on the balloon was 
outfitted with an omni-directional antenna with a 5 dB gain. A continuous ping 
confirmed proper connectivity between the two sites. There was a 95% or better success 
rate over a 15-minute period. 

On 9 March, the balloon was launched in order to provide connectivity 
between the NOG and POP. Due to the testing of the satellite link between the two sites, 
time was limited to establish connectivity through the balloon. Both the POP and NOG 
had EOS with the balloon, but the NOG and POP were BEOS. 
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In order to attempt to establish eonneetivity from the NOC to the POP via 
the tethered balloon, speeial settings needed to be placed on the WAP 11s. Again, 
WAP 1 Is were used at the NOC, POP, and on the balloon. Each site had omni-directional 
antennas with a 5 dB gain. The WAP 11 on the balloon was set for bridge mode but in 
point-to-multipoint mode. No MAC address or gateway IP address was necessary for this 
conhguration. At the NOC, the conhguration was set for bridge mode with a remote 
MAC address of the access point on the balloon, and the gateway was set for the IP 
address of the balloon’s access point. At the POP, the conhguration was the same as the 
NOC. Finally, the same cha nn el and Service Set Identiher (SSID) were set for ah three 
WAP 11s. 

The students were unable to establish connectivity between the NOC and 
the POP on 9 March. The students believed this was due to the position of the omni¬ 
directional antenna on-board the balloon. See the communications on-the-move section 
below for information on the tethered balloon relay. 

d. Unmanned Aerial Vehicle (UAV) 802,11b 

MLB Company of Mountain View, CA supported this testing event from 
March 9-11 with their “Volcano” UAV platform. The 55-pound Volcano aircraft is 
designed to carry a 15 lb payload up to an altitude of 12,000 feet. A 50 cc 2-stroke 
gasoline engine was customized for this aircraft, and it has an endurance of 2 hours at 40 
miles per hour. Furthermore, the Volcano’s flight control is done via autonomous 
waypoint navigation or direct radio control uplink. The Volcano UAV has been actively 
flying since December 2002.59 Figure 61 shows the Volcano aircraft. 


59 http://www.spvplanes.cotn/volcano.html (May 2004). 


128 





Figure 62. STEPHEN MORRIS AND MLB ’ S VOLCANO UAV 


This platform was utilized for communications relay during the testing 
event for nodes scattered throughout the training area. Kevin Jones from NPS built a 
wooden platform that was placed underneath the UAV. It contained the following; 
omni-directional antenna, Linksys access point, 1-Watt amplifier, DC to AC power 
converter, and one lithium battery. The omni-directional antenna pointed down through 
the wooden platform. This platform weighed about seven pounds and was attached to the 
UAV via three metal clipped straps that wrapped around the UAV and the platform. 
Eigure 62 shows the platform attached to the UAV. 
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Figure 63. MLB VOLCANO UAV WITH PAYLOAD 

On 9 March, Stephen Morris, President of MLB, and Hank Jones arrived 
with the Volcano and conducted familiarization flights along with some initial on-board 
communications tests. After these flights and tests, the wooden platform was mounted on 
the UAV. The aircraft was controlled with a handheld device by Mr. Morris to maneuver 
on the runway and take off. Only 500 meters of runway was needed to get the aircraft off 
the ground. After the UAV entered its flight pattern, which was programmed into the 
computer system that goes along with the aircraft, the students started to conduct 
communications testing with the aerial platform. 

The computer system and antenna used to control the Volcano can be seen 
in Figure 63. The frequency to control the aircraft was 900 MHz and the on-board 
camera used the 2.4 GHz band to transmit live video back to the ground control station. 
In the computer software program that was utilized to control the aircraft while in flight, 
waypoints and altitude information were entered onto a digital map of the desired flight 
pattern of the aircraft. Thus, as long as the ground antenna had LOS with the aircraft no 
manual movement with the handheld device was required while the aircraft was in flight. 
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Consequently, the software allowed the user to view the exaet pattern of the entire flight 
on a digital map after mission eompletion. 



Figure 64. MLB FLIGHT CONTROL GEAR FOR VOLCANO 


During the flight on 9 Mareh, 802.11b eonneetivity was attempted from 
the NOC to the POP via the UAV. Linksys WAPl 1 Aeeess Points were used at eaeh site 
and omni-direetional antennas with 5 dB gain and 1-Watt amplifiers were employed with 
the aeeess points. The setup of the aeeess points was the exaet same as the eonfiguration 
explained in the tethered balloon seetion. The ground aeeess points were set for point-to- 
point in bridge mode with the MAC address of the aeeess point on the UAV and a 
gateway IP address of the UAV’s aeeess point. The airborne aeeess point was set on 
point-to-multipoint with no gateway IP address. Unfortunately, very few pings were 
attained during ping eonneetivity testing on this day with the existing antennas, despite 
the UAV’s altitude of 500 feet and flying direetly between both the NOC and POP. 
Upon further researeh, the students determined that the omni-direetional antenna on the 
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UAV was not positioned very well. More sueeess would have been attained with the 
antenna by plaeing it on the aircraft in a position that allows for the most optimal 
radiation pattern. 

e. NetMeeting 

NetMeeting is a Microsoft Windows product that delivers an open, 
extensible platform for real-time communications, offering audio, video, and data 
conferencing functionality. 

During this testing event, the students utilized NetMeeting as a tool to 
transmit live video between the sites via Logitech cameras set up in each LAN, to talk via 
headsets hooked up to the computer, and to perform data messaging between users at all 
sites. On 11 March, MRC #2 was able to see video in NetMeeting after traversing a 
satellite link, 802.1 lb through the tethered balloon, and OFDM from the NOC. 

f. VoIP 

See the LOS section for VoIP explanation during the testing event. No 
direct testing was done with VoIP when traversing solely BLOS technology (OFDM, 
tethered balloon, or UAV). Instead, IP phones were employed through a multitude of 
technologies. For example on 9 March, when MRC #2 wanted to talk to the NOC over 
the IP phone, the phone would first communicate with the Call Manager server over 
OFDM and then through the broadband satellite link resulting in a successful phone 
connection. There was a slight delay when talking through these means but the quality of 
service was not affected. However, when making a phone call on 11 March from MRC 
#1 through the tethered balloon to the POP and then to the NOC via satellite, there were 
quality of service issues as the link between MRC #1 and the POP over the balloon was 
experiencing more than 20% packet loss. The phone would occasionally lose 
connectivity due to this packet loss. 

3. Over-the-Horizon (OTH) 

a. Segovia/Omega Systems 

Segovia and Omega Systems supported this exercise from March 7-11 
with Jeff Howard, Sales Director, and Ross Warren, Senior Sales Engineer, from Segovia 
and Matt Jones, Vice President Business Development, from Omega Systems. Segovia is 
the service provider of the satellite system and Omega Systems produces the satellite 


132 



dishes. During this event, a one-meter satellite ground terminal was utilized at the NOC, 
and a mounted one-meter satellite terminal on a Sports Utility Vehicle was employed at 
the POP. The ground terminal is a multiple case system that is powered by a llOV 
source, and its transmitting frequency is between 13.75-14.50 GHz with a receiving 
frequency between 11.70-12.75 GHz. This satellite dish is manually pointed at the 
satellite for connectivity. Figure 64 below shows the ground terminal in the foreground. 



Figure 65. SEGOVIA/OMEGA SYSTEMS GROUND TERMINAL 


The mounted terminal requires the same power load and it operates in the 
same frequency band. However, it automatically aligns itself to the satellite once it is 
turned on. This yields for a quick setup time and operations of the equipment can begin 
within minutes. Figure 65 illustrates the mounted satellite terminal. 
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Figure 66. OMEGA SYSTEMS MOUNTED SATEEEITE TERMINAE 


Both terminals are eapable of Type 1 eneryption to provide for a secure 
satellite connection, and the throughput for the services can range from 128 Kbps to 9 
Mbps. 

During this testing event, the personnel from Segovia and Omega Systems 
demonstrated their flexibility with the setup of the terminals and the services that they 
provided. Segovia’s Ross Warren was able to coordinate with his headquarters in order 
to arrange for the airborne satellite to act as a retransmission site for the link between the 
NOC and the POP (The satellite link was double-hopping between the NOC and POP). 
See Eigure 66 below for latency between the NOC and POP. Prom the table, one can see 
the time is roughly one second to ping between the two sites. By comparison, within a 
EAN two computers can ping each other with a time of less than 10 milliseconds. 
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Reply from 192.168.5.20: bytes=32 time=1032ms TTL=123 
Reply from 192.168.5.20: bytes=32 time=1011ms TTL=123 
Reply from 192.168.5.20: bytes=32 time=1012ms TTL=123 
Reply from 192.168.5.20: bytes=32 time=1021ms TTL=123 

Ping statisties for 192.168.5.20: 

Paekets: Sent = 4, Received = 4, Lost = 0 (0% loss), 

Approximate round trip times in milli-seconds: 

Minimum = 1011ms, Maximum = 1032ms, Average = 1019ms 

Figure 67. LATENCY DATA WITH SEGOVIA LINK 

The satellite services of Segovia were only intended to be used for 
retransmission, not for Internet connectivity or to provide phone services. Even though 
Segovia would have been able to arrange Internet services with a retransmission 
capability, the students did not pursue this option. Not only did Mr. Warren provide 
customer support for his equipment, but he also went above and beyond by assisting the 
students with the configuration of the entire network of routers, switches, access points, 
and IP phones. 

On 7 March, Segovia established their satellite links and became familiar 
with the entire network setup. They had to configure their gear appropriately to plug- 
and-play with CAT-5 cable from their system into the established network router. 

The next day (8 March), Segovia spent the morning arranging with their 
headquarters to retransmit the signal between the NOC and POP. In the late afternoon, 
after OFDM testing was complete between the NOC and POP, Segovia successfully 
tested their setup while connected to the network. 

On 9 March, Segovia established their link for the entire day with the 
ground terminal at the NOC and the mounted dish at the POP. They had their settings for 
bandwidth set very low, which was not even close to their maximum capabilities of 9 
Mbps. Figure 67 below shows the Iperf test conducted on the link between the NOC and 
POP with 64 Kbyte size packets flooding the link. 
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Client connecting to 192.168.5.5, TCP port 5001 
TCP window size: 63.0 KByte (default) 


[928] local 192.168.20.3 port 1433 connected with 192.168.5.5 port 5001 


[ ID] Interval 
[928] 0.0-5.1 sec 
[928] 5.1-10.6 sec 
[928] 10.6-16.0 sec 
[928] 16.0-20.1 sec 
[928] 0.0-23.3 sec 


Transfer 
192 KBytes 
40.0 KBytes 
40.0 KBytes 
32.0 KBytes 
304 KBytes 


Bandwidth 
298 Kbits/sec 

59.1 Kbits/sec 
59.4 Kbits/sec 

62.2 Kbits/sec 
104 Kbits/sec 


Figure 68. IPERF DATA ON 9 MARCH FROM SEGOVIA’S EINK 


After Segovia arranged for their bandwidth capabilities to be much higher 
on 10 March, Iperf data was much more consistent and higher. The first test conducted 
was with Iperf when no IP phone traffic or data was being sent from the NOC to the POP. 
Eigure 68 shows this data. 


Client connecting to 192.168.5.20, TCP port 5001 
TCP window size: 63.0 KByte (default) 


[928] local 192.168.20.3 port 1049 connected with 192.168.5.20 port 
5001 


[ ID] Interval 
[928] 0.0- 5.1 sec 
[928] 5.1-10.1 sec 
[928] 10.1-15.1 sec 
[928] 15.1-20.1 sec 
[928] 0.0-22.3 sec 


Transfer 
640 KBytes 
616 KBytes 
632 KBytes 
608 KBytes 
2.4 MBytes 


Bandwidth 
1.0 Mbits/sec 

986 Kbits/sec 
996 Kbits/sec 

987 Kbits/sec 
897 Kbits/sec 


Eigure 69. IPERE DATA ON 10 MARCH WITH SEGOVIA’S EINK 


After this was complete, data was collected with Iperf on the satellite link 
when a Cisco IP Phone was utilized to place a call between the NOC and POP (This was 
a phone call placed by using VoIP within the network not Segovia’s phone services). 
When the Iperf packets flooded the network, the IP phone started experiencing a one to 
two second delay, but voice quality was still excellent. However, it became evident that 
the bandwidth would drop considerably when a phone call took place. Eigure 69 below 
illustrates the data collected. 
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Qialoonmctingto 152.168.5.20, TCPpcrtSOOl 
ICP-MiiijwsizE: 63.0KE^((fcfeult) 


[928] local 19216820.3 pert 1052 ocmected \Mth 192168.5.20 pert 5001 

[ ID] Irtmal Transfo' Bandwidth 

[928] 0.0-5.2 sec 184 KBytes 282Kh8ts'sec 

[928] 5.2-10.7 sec 40.0 KBytes 58.1Khiits'sec 

[928] 10.7-15.1 sec 320 KBytes 58.9Kbits/sec 

[928] 15.1-20.6 sec 40.0 KBytes 58.1 Kbits'sec 

[928] 20.6-25.8 sec 40.0 KBytes 61.6Kbits'sec 

[928] 25.8-31.1 sec 40.0 KBytes eO.OKtjts/sec 

[928] 31.1-35.3sec 320KBytes 61.3Kbits^sec 

[928] 35.3^.6 sec 40.0 KBytes 60.3 Kbits^sec 

[928] 40.645.5 sec 48.0 KBytes 78.6Kbits'sec 

[928] 45.650.3 sec 152 K^ 252Kbits'sec 

[928] 50.655.3 sec 40.0 KBytes 63.8Kbits/sec 

[928] 55.660.9 sec 40.0 KBytes 57.4Kbits/sec 

[928] 60.965.0 sec 320 KBytes 623Kbits'sec 

[928] 65.0-70.2 sec 40.0 KBytes 61.6Kbits'sec 

[928] 70.2-75.8 sec 40.0 K^ 57.2Kbits'sec 

[928] 75.8-80.1 sec 320 K^ 59.2Kbits'sec 

[928] 80.1-85.1 sec 40.0 KBytes 61.2Kbits'sec 

[928] 85.1-90.8sec 192K^ T/OKbits/sec 

[928] 90.8-95.2 sec 320 K^ 58.8Kbits'sec 

[928] 95.2-100.3 sec 40.0 KBytes 623Kbits'sec 

[ ID] lrta\al TransfCT Bandwidth 

[928] 0.0-103.2 sec 1.1 Miytes 91.1 Kbilstsec 


Figure 70. SEGOVIA IPERF DATA ON 10 MARCH WITH IP PHONE 


The last day of the testing was a eomplete sueeess as Segovia’s link 
provided a stable eonneetion between the NOC and POP as the students worked to 
establish 802.1 lb through a tethered balloon and OFDM on-the-move throughout the rest 
of the network. 

Overall, Segovia and Omega Systems provided a solid satellite link with 
less than 10 minutes of down time throughout the week. They proved their versatility by 
being able to use the satellite as a retransmission deviee within a private network. 
Normally, they are an Internet and phone serviees provider. Furthermore, the mounted 
terminal proved to be a paekage that Marines eould utilize with a mobile unit. With its 
self-aequiring eapabilities, the unit ean be up and running within minutes. Omega is also 
working on a paekage that ean eommunieate while on the move. 

b. Neva 

Nera supported this exereise from Mareh 9-11 with Torgrim Jorgensen, 

Senior Sales from the Norway offiee, and Peter Coffman, Sales Direetor out of the Texas 

offiee. Nera’s NWC Voyager system, INMARSAT eapabilities on-the-move, was 

utilized in the eonvoy on 11 Mareh. In addition, Nera’s World Communieator was 

137 




demonstrated on 10 March but not used as planned during this testing evolution. See the 
Appendix for further explanation of the NWC Voyage and World Communicator. 


During this testing, the NWC Voyager was mounted on a custom built 
wood platform in the back of a pickup truck. The platform was specifically built so that 
the satellite antenna would clear the bed of the truck. Figure 70 below shows this set up. 



Figure 71. NERA INMARSAT MOUNTED ON VEHICLE PLATEORM 


The objective for the Nera satellite system during this event was to bounce 
the signal between the Voyager at MRC #1 and the World Communicator at the NOC, 
much like what Segovia/Omega Systems did with their satellite link. This would be the 
WAN connection between the two LANs. The NWC Voyager on MRC #1 would 
provide connectivity for the entire convoy to talk back to the NOC since there was an 
OEDM link between the vehicles. Then, the NOC would communicate with the POP via 
Segovia’s satellite link to complete the connectivity between all nodes. However, after 
two days of working on the above configuration it was determined that this setup could 
not be accomplished with the available gear that Nera had on hand. 

In order to test the capabilities of Nera’s system, the students employed 
the Internet and phone connectivity capabilities in MRC #1 with the Voyager system. A 
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phone was connected to the modem in MRC #1 and another cellular phone was placed at 
the NOC. MRC #1 was also equipped with a laptop that connected to the Voyager 
modem, which provided Internet connectivity. Figure 71 below shows the phone and 
modem. While MRC #1 was in motion with the mounted Voyager, phone calls and most 
file downloads were performed without error. When the look angle of the Voyager was 
blocked by hills next to the vehicle, the download capabilities were temporarily 
terminated. 


1^ 

( 



Figure 72. NERA’S PHONE AND MODEM 

During the first phone call between MRC #1 and the NOC, a 4.6 Kbps rate 
was used. However, during the second phone call, a 64 Kbps rate was used and the voice 
quality was much better. Neither of the rates produced any noticeable time delay during 
the phone call. Eile downloads were conducted for demonstration of the Internet 
connectivity. Eirst, a 1.2 Mbyte file took 11 minutes and 35 seconds to download. Next, 
a 2.8 Mbyte file took 16 minutes and 32 seconds to download. Since the link between 
MRC #1 and the NOC with Nera’s equipment could not be accomplished, the World 
Communicator was not used. 

Overall, Nera was able to demonstrate their capabilities on the move. The 
Nera representative did explain that they could make the configuration work that was 
originally intended if they had the appropriate equipment. This LAN-to-LAN 
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connectivity would have shown the ability to maintain conneetivity while on the move. 
A scenario that this is applieable to is when main and forward eommand posts echelon, 
whieh usually eauses them to lose most of their data eapabilities, but with INMARSAT 
these eommand posts eould eontinue to exehange desired data, 
c. VoIP 

Within the LOS seetion, VoIP is explained in greater detail. One of the 
main objeetives for the VoIP element was to determine if there was any quality of serviee 
issues over a satellite link. The link between the NOC and POP was a Segovia/Omega 
System satellite serviee, and there was no quality of serviee issues with VoIP, despite this 
link traversing two hops from the NOC to the POP. There was a slight delay when 
talking but the elarity of voiees was near perfect. Finally, several IP phone ealls eould 
have overloaded the satellite link’s throughput of 1 Mbps and eaused a quality of serviee 
issue. 

4, Communications on-the-Move 
(L OFDM 

(1) Redline Communications. On 10 March, Redline’s equipment 
was deployed on-the-move. The sector antennas were plaeed on five-foot stands 
mounted on a wooden platform in the vehieles. The seetor antennas had 60-degree 
beamwidth and the other was a tighter beam of 5-degrees. The AN-50 system was plaeed 
within the bed of the piek-up trueks. The goal of the on-the-move portion was to 
maintain eonneetivity via OFDM while the two eonvoy vehieles were BLOS. As the 
vehieles started in motion, both MRC #1 and #2 established a eontinuous ping test. This 
enabled the students to see how well the link maintained eonneetivity. The results were 
favorable sinee eonneetivity was seldom lost and only for seeonds when vehieles turned 
eomers or when a hill interfered. This was also being done with sector antennas, so this 
eould have played a role in the degraded eonneetivity. At the end of the day, Redline 
established an omni-direetional antenna with a seetor antenna to ensure that eonneetivity 
was maintained. This also worked and may be a better solution if the omni-direetional 
antenna has enough gain to meet the distanee of the eonvoy. Figure 72 below shows 
Redline’s setup for the eommunieations on-the-move. 
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Figure 73. REDLINE ON-THE-MOVE SETUP ON BOTH VEHICEES 


(2) Alvarion. Because of a lack of time, Alvarion did not deploy 
their system on-board MRC #1 and #2 on 10 March while communications on-the-move 
were being evaluated. However, Mr. Constantino attempted to use Alvarion’s 802.11b 
omni-directional system to establish connectivity with the UAV while it was airborne. 
Unfortunately, the UAV had a Linksys AP on-board which was not compatible with any 
other type of equipment. 

On 11 March, Alvarion’s equipment was employed on MRC #1 
and #2 to establish connectivity between the vehicles while on-the-move. One vehicle 
employed an AU-VL 5.8 GHz Omni antenna with an 8 dB gain. The other vehicle 
utilized a SU-VL integrated antenna with a 10-degree beam width. The integrated 
antenna had a 21 dB gain. While on the move and with the vehicles BEOS of each other, 
the OEDM link was stable as both vehicles were continuously pinging each other. There 
were a couple of areas where connectivity was lost between the vehicles. This mostly 
occurred as one vehicle would turn a comer and get a hill between the two vehicles. The 
lapse of coverage only happened momentarily as the link reestablished itself. No data 
was collected using Iperf or Q-Check. Eigure 73 below shows the antenna setup on the 
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convoy vehicles. The antennas were mounted on a pole that was attaehed to a tripod. The 
tripod was then bolted down to a wooden platform in the bed of the truek. 



Figure 74. ALVARION ANTENNA SETUP ON POLE 

b. 802.11b (balloon) 

On 10 Mareh the lead vehiele in the eonvoy, MRC #1, was equipped with 
an omni-direetional antenna. Conneetivity was attempted between MRC #1 and the POP 
site via the tethered balloon. The setup of the WAPl Is at MRC #1, POP, and the balloon 
were the exaet same as explained above in the BEOS section. When attempting the relay 
from the NOC to the POP on 9 Mareh, again eonneetivity eould not be established 
between the two nodes. Ping tests were being done that showed the laek of eonneetivity. 

Next, MRC #1 reconfigured the WAP-11 in order to establish eonneetivity 
with the tethered balloon direetly while stopped on the side of the road. Again, the 
eonfiguration was similar to what was set up on 8 Mareh between the NOC and the 
tethered balloon. This time MRC #1 used a Yagi direetional antenna with a beamwidth 
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of 30 degrees and gain of 14.5 dB. And for the first time, sueeessful pings were 
established between the two nodes. After this was aeeomplished, both MRC #1 and the 
POP utilized the same Yagi antennas and intermittent eonneetivity was attained between 
the two sites via the balloon. This day was fairly windy, so the balloon was moving quite 
a bit while deployed to 1,000 feet. When eondueting ping tests between the POP and 
MRC #1, a 50% paeket loss was reeorded. 

A ealm day on 11 Mareh proved to be more suitable for the deployment of 
the balloon as results showed mueh more stable eonneetivity. The same setup was 
employed as on 10 Mareh with MRC #1 and the POP using Yagi antennas eonneeted to 
the WAPl Is and MRC #1 stationary. The reason for testing while stationary was that the 
Yagi antenna needed to be plaeed on a mount to maintain eonneetivity with the balloon. 
If the vehiele was moving, the antenna would have been required to be manually pointed 
at the balloon. A traeking antenna on the ground would be mueh more suitable for this 
type of operation. 

c. 802.11b (UAV) 

On 10 Mareh, MRC #1 was equipped with a Linksys WAP 11 and an 
omni-direetional antenna with a 1-Watt amplifier. Conneetivity was attempted from 
MRC #1 on the move with the NOC through the Voleano UAV. The UAV was flying at 
500 feet between the two sites and within LOS. The students were unable to establish 
eonneetivity while pinging from the NOC to MRC #1. Next, the eonvoy of vehieles 
stopped and MRC #1 set up a Yagi antenna with 14.5 dBi gain and eonfigured the aeeess 
point to go point-to-point with the airborne aeeess point. The UAV landed and the aeeess 
point was also reeonfigured for point-to-point with MRC #1. After reestablishing its 
traek at 500 feet, MRC #1 traeked the UAV manually with the Yagi antenna and started 
to see better eonneetivity. Eighteen of 22 pings were sueeessful. The UAV went up to 
1,000 feet and the ping ratio deereased to two of 20 sueeessful pings. At 800 feet, the 
ratio was six of 20 pings. With the laek of eommunieations relay on this day, the UAV 
platform was never integrated into the wide area network. 

Testing the next day resulted in little change as far as retransmission. 

Connectivity was attempted from the NOC to the POP once again but this time the POP 

had a Yagi antenna tracking the UAV. No successful pings were attained even while as 
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low as 400 feet. Figure 74 below illustrates the view of the UAV looking down on the 
POP site. As mentioned earlier, the omni-direetional antennas needed to be better plaeed 
on the aireraft to allow the radiation pattern of the antenna to emit its proper signature. 



Figure 75. UAV LOOKING DOWN ON POP SITE ON 11 MARCH 


Overall, MLB Company remained flexible throughout the three days of 
testing. They flew at varying altitudes and ehanged eourse numerous times to meet the 
needs of the experiment. They were able to provide the support the students expeeted, 
but prior testing needed to be done to test the antenna set up. 

d. 802,11a (vehicles) 

The Wireless 802.11a LAN in the moving vehieles on Mareh 10-11 was 
espeeially helpful as the networking equipment (routers, switehes, aeeess point) were all 
loeated in the bed of the piek-up trueks. The operator with the laptop was loeated in the 
passenger side of the vehiele. Therefore, the operator did not have to run a eable between 
the bed of the truek and the eab. Tests were not condueted to determine the actual 
throughput of the 802.1 la link. 

This field-testing event proved very challenging due to the complexity of 
the network and the numerous moving parts. However, after battling through the issues 
that came up, the network communications architecture that was desired for CoNDOR 
was accomplished on the last day. Figure 75 shows the connectivity between the NOC 
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and MRC #2. The ping test went through three different technologies: satellite link, 
802.1 lb retransmitted through a tethered balloon, and OFDM. 


From .20.3 to .80.3: 

Pinging 192.168.80.3 with 32 bytes of data: 

Reply from 192.168.80.3: bytes=32time=1031msTTL=120 
Reply from 192.168.80.3: bytes=32 time=1052ms TTL=120 
Reply from 192.168.80.3: bytes=32 time=1051ms TTL=120 
Request timed out. 

Reply from 192.168.80.3: bytes=32 time=1041ms TTL=120 
Reply from 192.168.80.3: bytes=32 time=1072ms TTL=120 
Reply from 192.168.80.3: bytes=32 time=1032ms TTL=120 
Reply from 192.168.80.3: bytes=32 time=1081ms TTL=120 
Reply from 192.168.80.3: bytes=32 time=1062ms TTL=120 
Request timed out. 

Request timed out. 

Ping statistics for 192.168.80.3: 

Packets: Sent =11, Received = 8, Lost = 3 (27% loss), 
Approximate round trip times in milli-seconds: 

Minimum = 1031ms, Maximum = 1081ms, Average = 765ms 


Figure 76. PING TEST FROM NOC TO MRC #2 


In this testing evolution, the students were able to show that multiple 
technologies can be employed in a WAN as long as everything is IP based and the 
appropriate routing schemes are employed. 
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III. FINDINGS AND ANALYSIS OF EACH TESTING EVENT 


A. FIELD TEST #1 (FORT ORD AND BIG SUR, CA) 

1, Findings 

The findings discovered during this testing event are discussed chronologically. 
The chronological order consists of testing with lEONA and Lightpointe’s FSO products, 
RF and FSO employed together, data transfer time latency tests, throughput analysis 
when covering lasers on link head, and 802.1 lb with Linksys WAP 1 Is. 

During the ISONA free space optics equipment tests, a maximum throughput with 
ISONA’s link was roughly 13 Mbps when sending files across the network from one 
laptop computer in one local area network (LAN) to another laptop in a second LAN. 
Although the ports on the switches were capable of 100 Mbps, the authors concluded that 
the configuration of the routers and switches in the network caused the degradation in 
throughput. In a configuration where the authors bypassed the routers and switches, 
going from one laptop connected to the FSO link to another laptop on the other end, the 
authors determined by using IPERF software that the link could support up to 50 Mbps. 
The lesson learned during this phase of the experiment was that the computer’s network 
interface card, routers, and switches in both local area networks would need to be 
configured at 100 Mbps full duplex. This configuration standard for both local area 
networks was therefore set for follow-on experiments. 

Three tests were conducted with Lightpointe equipment. One test involved 
determining whether a Cisco 2950 switch was capable of handling RF and FSO 
simultaneously. Another test with Lightpointe gear measured the time latency of the 
laser product by transferring data files across the network while measuring throughput 
across the network. The final test involved covering sectors on the laser optic and 
measuring the throughput in order to determine whether this type of test would be 
beneficial for further testing. 

The authors revealed that the Cisco switch was not able to dynamically switch 
between RF and FSO while both links were attached to the switch. This Cisco 2950 
switch was not designed to accept two different types of media. In addition, this 


147 



particular switch was not configured to take the higher throughput. After reeonfiguring 
the switeh to aeeept FSO only, the authors were able to achieve 10 Mbps higher readings 
between sites. Furthermore, the authors were able to aehieve a throughput of 45 Mbps 
after doing a quick optimization of routers and switehes. The lesson learned was that the 
equipment being used should be eonfigured to handle the maximum throughput. In 
addition, the equipment should be eonfigured for maximum throughput in the lab instead 
of in the field in order to maximize experimental time in the field. 

The second test was the time lateney test. Data files were transferred from one 
loeal area network to another and the time to transfer files aeross the network was 
measured. The results indieated that the time annotated (aetual time for the data to 
traverse from one network to another) was not the same as the expeeted time for the data 
to traverse aeross the network. For example, expeeted time to transfer a 100 Mbyte file 
over a 50 Mbps link should be 2 seconds. The reason for the differenee in time is that 
other faetors are involved when data is transferred from one laptop in one loeal area 
network to another. Some of these faetors inelude the buffer size of the reeeiving and 
sending eomputers (the sending and receiving computer’s buffer size temporarily stores 
the amount of data that is going to be sent); the proeessing speed of the eomputer sending 
or reeeiving the data; the type of file being transferred; the quality of serviee that is taking 
plaee within the TCP flow eontrol (TCP uses a eredit alloeation seheme); and the time 
delta (time delta is the ehange in time that it takes to start the stop wateh and for the 
aetual time for the experiment to start). The lesson learned was to always be eognizant of 
factors outside the seope of the experiment that may affect the results obtained. 

The third test involved a measure of throughput while eovering eertain seetors of 

Lightpointe’s link head. During this test, seetors on the laser were covered with a 

eardboard box. The throughput was measured to see if eovering the laser’s link head had 

any effeet on the throughput. The results indieated that the throughput remained 

eonsistent at its maximum value (45 Mbps) regardless of the sector covered. Finally, the 

entire link head was eovered to break its signal. It took a 20-seoond time interval to 

reaequire the signal after the link head was uneovered. Twenty seconds was the time the 

Ciseo produets needed in order to reeognize deviees aeross the network, meaning the 

laser produet was not the reason for the delay. The lesson learned was that no matter how 
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much of the link head was covered the laser was still able to transfer data between the 
two sites at the same rate until the link head was eompletely covered. 

The last item tested for the Big Sur experiment was 802.11b with a Linksys 
Access Point (AP-WAP 11). The purpose of this experiment was to measure the 
throughput of 802.11b with yagi and parabolic antennas (see Chapter 1 for 
specifications). The antennas were connected to the aceess points, which were 
configured in bridge mode. The results indicated that the parabolic antenna had better 
results when eompared to the yagi antenna. In addition, NetMeeting was tested in an 
attempt to share files between the two loeal area networks. It was determined that 
NetMeeting had a maximum throughput limit of 1.27 Mbps. The lesson learned was that 
the parabolic antenna was eapable of greater throughput over a longer distanee 
(charaeteristics of the antenna). In addition, the maximum amount of throughput that can 
be transmitted when using NetMeeting is 1.27 Mbps. 

2. Analysis 

The analysis for this field test was a straightforward observation of ensuring that 
the test bed was configured for maximum throughput. The configuration for the test bed 
items sueh as routers, switehes, and laptops were eonfigured at full duplex, speed 100 
Mbps. In addition, an understanding of equipment characteristies, sueh as TCP flow 
control between computers and router and switeh configurations, were vital in obtaining 
the results. Field Test One was a basic “kick the tire” exereise (familiarization exereise) 
that proved to be very valuable in subsequent experiments. 

B, FIELD TEST #2 (GENERAL DYNAMICS) 

The findings diseovered during the General Dynamics testing event are discussed 
below. General topics such as SolarWinds and Iperf differences and throughput testing 
from computer to computer are first discussed. Then, the findings for following produets 
are mentioned; 802.1 lb over SeeNet-11, Radio Frequeney Module (RFM), Cisco Gigabit 
Interface Cards (GBICs), MRV, Lightpointe, Ensemble, Digital Switch Unit, KG-235, 
and Iridium Inverse Multiplexer (IMUX). 
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1, Findings 

In order to accurately measure the throughput of the different technologies used to 
connect the two LANs, the authors utilized programs called SolarWinds and Iperf. They 
were significantly different in their capabilities since SolarWinds is a tool to measure 
throughput within a network and Iperf is used to generate data and then measure the 
throughput. In order to generate data traffic for SolarWinds to measure throughput, the 
authors used Windows fide sharing between computers where various types and sizes of 
files were sent. This type of traffic generation varied considerably from the specific size 
packets that Iperf generated. Due to the difference in traffic generation between the two 
programs, each program provided different throughput readings. This was done 
intentionally. 

On another aspect of throughput testing, the authors noticed that sending data 
from computer to computer on different LANs was significantly slower than sending data 
between computers that were directly connected to the link technology product, such as 
FSO. The traffic generated within the LAN was more realistic and thus was the preferred 
choice, since it would be rare to directly connect a computer to the link technology 
product. 

The first technology tested was 802.1 lb over SecNet-11. Once all the equipment 
was set up and data was transferred between the two LANs, a noticeable difference was 
found when transferring data from the 192.168.3.x network to the 192.168.Lx network 
compared to transferring data from the 192.168.Lx to 192.168.3.x network. The 
throughput from the .3 to the .1 network was 1.1 Mbps and from the .1 to the .3 network 
it was 500 Kbps. These tests were done independently from one another, so data was not 
transferred both ways simultaneously. The packet loss when transmitting data was 10 to 
15% throughout all the different test readings. This was quite high for a short distance of 
500 meters and for high gain antennas. 

Next, testing was conducted with a SecNet-11 access point placed in the Mobile 
Research Facility’s (MRF) LAN. The access point was connected to the Cisco 2950 
switch via CAT-5 cable. Data was collected when transferring files between two wireless 
laptops in the LAN associated with the SecNet-11 access point. In addition, data was 
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obtained when transferring files between one wireless computer associated with the 
access point and one computer connected to the LAN switch. There was considerable 
difference in the data throughput as the wireless-to-wireless test produced a throughput of 
2.3 Mbps, and the wireless-to-wired test produced a throughput of 4.5 Mbps. 

The GDDS RFM product came with a Cisco 2950 switch in the carrying case. 
This device interacted with the local equipment and the established network. The ports 
on the switch were automatically set for auto-negotiation, but an assumption can’t be 
made that CAT-5 coming off this switch can plug-and-play with any network. 
Consideration needs to be given to the speed and type of transmission, which need to be 
set on each port in order to successfully attain the highest throughput of the RFM 
product. When the ports on the RFM switch were not set appropriately, the average 
throughput measured in Iperf was 27.4 Mbps. After the ports were configured correctly 
to match the existing network, the throughput measured 52.3 Mbps. 

When the authors originally requested a temporary loan of Cisco 3745 routers, 
they requested GBICs to insert into the router cards, which enabled a fiber connection 
from the FSO products. IBONA was the first FSO company to set up their product, so 
they ran their single-mode fiber cable into the GBIC on the router. The physical 
connection was appropriate as the cable and port were both Subscription Channel 
Connector (SC) capable. However, a link light was not showing on the router card. 
Since ISONA uses a wavelength of 1550 nanometers for their lasers and single-mode 
fiber to come off of the link head, they needed a GBIC that supported a 1310 nanometers 
wavelength and the single-mode fiber. As the authors researched the Cisco GBICs, they 
found that they possessed only lOOOBASE-SX GBICs, which accept a wavelength of 850 
nanometers and multi-mode fiber. This proved to be the reason why ISONA could not 
connect their link head directly with the network router via a fiber cable. ISONA needed 
the Cisco lOOOBASE-ZX GBIC. After this failed connection, ISONA used their media 
converters to connect to the network with a CAT-5 cable and experienced 56 Mbps of 
throughput measured by SolarWinds. 

MRV Communications also utilized their own media converters to convert their 
ESO product to the network router. Their product utilized the 850 nanometers 
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wavelength range but no attempts were made to go directly to the router from their link 
head. The use of the media converter enabled MRV to come off their link head with fiber 
cable and connect to the router with a CAT-5 cable. MRV’s throughput data readings 
were inconsistent between 15-52 Mbps on Iperf, and the media converter was identified 
as the possible problem. MRV’s converter had certain settings that needed to be set on 
the small dials located on the side. After adjusting the settings, the data obtained showed 
continual improvement. However, the throughput was still not quite right. Since time 
was limited, MRV personnel conducted further testing in their labs after the testing event; 
and the results showed that the media converters were not set appropriately during the 
testing event. 

The next FSO company, Lightpointe, connected their FlightStrata directly to the 
network routers. Their product used multi-mode fiber cable, and it operated at the 
wavelength of 850 nanometers. Since the GBIC ports on the routers were made for this 
exact type of fiber and wavelength, and an SC-type connection was used for the link head 
and GBIC, Lightpointe attained successful results of 80.3 Mbps on Iperf from the very 
beginning of the day. 

Ensemble’s 802.16 product attained lower data throughput readings than the other 
high throughput technologies such as FSO and Microwave. While Ensemble promoted 
their product at 66 Mbps of throughput, the actual capability when transmitting one way 
was 33 Mbps and the rest was reserved for traffic flowing the opposite direction. Data 
throughput averaged 10 Mbps, which was low comparatived to other companies. Most 
companies attained at least 50% of their link capability as measured by SolarWinds or 
Iperf. One reason for this slow speed was that Ensemble used a single-mode fiber cable 
to connect to the GBIC port on the router. Eortunately, the GBIC accepted the single¬ 
mode cable, even though the GBIC was designed for multi-mode fiber. Second, 
Ensemble’s single-mode fiber was equipped with an ST connector. Thus, an ST to SC 
converter had to be used between the cable and GBIC port. On another topic, the ATM 
configuration on the network router for Ensemble’s product proved to be inconvenient 
and time-consuming. There was no plug-and-play capability like the IP based 
technologies. 


152 



GDDS brought out their DSUs for this testing event. These devices normally 
allow users in the COC to access any radio or phone line that is located on the Antenna 
Hill. While the accessing of radios and phone lines was not attempted during this testing 
event, the ability to communicate VoIP through the DSUs was demonstrated. A DSU 
and GDDS’s laptops with the appropriate GUI software were connected to the LAN 
switch on both sides of the network to enable this to happen. However, in order to 
accomplish this, both networks needed to be on the same subnet. This was a drastic 
change from the three separate subnets utilized throughout the testing. While this was 
beneficial to demonstrate, it showed the current limitations of the DSU. Serious 
consideration needs to be given to how this can be employed when COC to COC and/or 
COC to Antenna Hill communication is required. 

As mentioned earlier, VoIP was utilized through the DSUs. It was also 
accomplished through the use of the Cisco IP phones in the network. SolarWinds read 
the throughput of a phone call at 90 Kbps no matter which technology was employed. 
Although this was not a significant amount of bandwidth utilized while employing high 
throughput technologies, it could prove to be a burden on the Marine Corps’ current 
equipment such as the MRC-142. With the use of multiple phones at the same time, the 
entire bandwidth could be taken up by voice only. 

The KG-235 INE crypto devices used during this event were intended to bulk 
encrypt all traffic over the wireless link being tested, except 802.11b with SecNet-11. 
This was done because the technologies did not have built-in encryption techniques. A 
trained KG-235 operator and the students determined that since the entire network was 
set up with three different subnets the KG-235 could not be placed between the link 
product and the network router. The 192.168.2.x subnet was established on the outside of 
each router and was the subnet of the wireless link between the two LANs. The two KG- 
235s needed to be on separate subnets to function properly together. Therefore, the 
router was eliminated in both networks and the KG-235 replaced it. The KG-235 at the 
MRF was set as the 192.168.3.x subnet and the other KG-235 was programmed for the 
192.168.1.x subnet. Unfortunately, the fill on the KG-235 at the MRF kept dropping, so 
the configuration on the KG-235 kept dropping out. Thus, no connectivity could be 
accomplished. 
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Finally, even though the IMUX deviee used to eombine four Iridium ehannels 
was not funetional during the testing, the authors were able to gain some insight into how 
the eapability eould fit into the Marine Corps eommunieations arehiteeture. Sinee the 
four antennas sit on a metal stand and eonneet to the IMUX box via an RF eable, the 
IMUX did not seem to be a means of eommunieation for on-the-move. It would have to 
be set up at a eompany-sized or larger COC. Speeial mounting options would have to be 
explored to mount the antennas on vehieles if there was a requirement to use it on-the- 
move. In addition, an Iridium phone must be attaehed to the IMUX deviee in order to use 
one of the ehannels. This is somewhat of an ineonvenienee, but there is an advantage 
beeause while using the phone others ean use the three other ehannels. A eompression 
algorithm sueh as the one Dr. Abousleman demonstrated to the students would need to be 
used with the Iridium serviee due to its low throughput eapabilities. 

2. Analysis 

The SolarWinds and Iperf data varied eonsiderably throughout the testing event. 
Iperf data always gave higher throughput readings due to the eonsistent size of paekets 
being generated from eomputer to eomputer. Although the SolarWinds reading is a more 
aeeurate depietion of how traffie will flow in the taetieal environment as various size 
files, e-mails, and phone ealls will be made, Iperf proved benefieial beeause it offered a 
quiek method to determine how mueh throughput eould be aehieved with an ideal load 
flooding the network from eomputer to eomputer. However, this seenario does not 
aeeurately depiet the traffie flow in any network. 

Another eause of the lower throughput data when measuring it from within the 
LAN eompared to eomputers direetly attaehed to the link is the ability of the routers and 
the switehes. When data is sent from the eomputer within the LAN, the switch and router 
may experience traffic entering the device faster than it can send it. Thus, significant 
overhead starts to build on the device and traffic in the network is slowed down. When 
the computers are connected directly to the link, the overhead factor is eliminated 
because there are no switches and routers to slow the traffic. The only limiting factor is 
the computer capability to send and receive data. 

When transferring data between two bridges, the SecNet-11 equipment required 

that one bridge be set at ‘Master’ and the other at ‘Slave’. The bridge at the side of the 
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192.168.3.x network was set for ‘Master’ and the other bridge at the 192.168.1.x network 
side was set for ‘Slave’. The throughput when going from ‘Master’ bridge to ‘Slave’ 
bridge was twiee as large as it was when going from ‘Slave’ to ‘Master’. The SeeNet-11 
bridges are designed for half-duplex transmission when communicating between the two. 
Therefore, when setting a bridge configuration to ‘Master’, there should be consideration 
for where that bridge is located, i.e., at a node where most of the traffic will be leaving. 
As for the packet loss in the bridge-to-bridge configuration, the parabolic antennas used 
required relatively accurate pointing due to their tight beamwidth of eight degrees. These 
antennas were most likely slightly off in their alignment, as the weather and distance 
were not a factor in causing the packet loss. 

The data collected for the SecNet-11 access point showed that there were 
significant disadvantages of going to a completely wireless LAN. The ability of the 
access point to transfer data expeditiously drops off as more wireless computers are used 
on the access point. It may be beneficial to have the users requiring wireless connections 
do so, but the ones who can stay near the access point and networking equipment remain 
wired. In addition, the computer wired to the network does not require a SecNet-11 card 
because the traffic from the wireless computer to the access point is encrypted, but the 
access point decrypts the traffic prior to routing it over the CAT-5 cable from the access 
point to the switch. 

Since the Cisco switch provided with the RFM product was set for auto¬ 
negotiation, and the network Cisco routers and switches were set for speed 100 Mbps and 
full duplex, serious degradation in the RFM link was apparent. The ports on the RFM 
Cisco switch need to be configured the same as the network ports. This allows for a more 
stable and reliable RFM link. 

INONA needed a different type of GBIC on the router to directly connect their 
single-mode fiber from the link head. Great lessons were learned about fiber connectors. 
First, the type of fiber connector was important since there are a multitude of connectors 
and many of them look similar. Next, the wavelength and type of mode that a port, such 
as a GBIC, supports was important to identify early on. These two important points can 
be easily overlooked, but will affect connectivity. 
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MRV’s media converter problems showed the need of knowing the media 
converter and the proper settings. Each company came to the testing event with different 
converters, and none were set the same way. For some reason, the MRV media converter 
needed the dials on the side of the device to be set; and most of the other companies’ 
media converters did not require this type of setting. The authors recommend using a 
media converter that is plug-and-play. 

Lightpointe enjoyed the success of directly connecting their link head to the 
network router with fiber, and they also experienced the highest throughput results of all 
the FSO companies. By eliminating the need for the media converter, Fightpointe was 
able to avoid the change in cable that the other companies encountered by going from 
fiber to CAT-5. In order to address the issue of the different types of GBICs required, a 
solution was to have one available for all the different types of fiber and wavelengths on 
hand. The GBIC could be easily switched out on the Cisco router. The use of fiber 
anywhere in the network would significantly increase the throughput capabilities. 

Ensemble would have been better served with a proper single-mode capable 
GBIC. While having the different types of interface converters on hand is convenient, a 
media cross connect device that connects all the types of connections and different 
wavelengths would be beneficial. MRV Communications makes this type of device, 
where any type of fiber connection can be added to the device to give a multitude of 
options for wavelength and connector capabilities. In addition, on the same device, 
copper and serial connections can be added. Far too often, the authors found themselves 
struggling with an array of connections that the different companies required. 
Furthermore, ATM type products required too many configurations on the routers and 
offered no benefit over IP based products. Therefore, the Marine Corps should adopt IP 
based technology. Ensemble did inform the authors that they were developing an IP 
based product. However, in April the board of directors for Ensemble decided to shut the 
company down. 

The DSU testing was a success due to the ability to talk via VoIP from the laptop 
computers. Since the DSUs are normally employed for COC to Antenna Hill scenarios, 
the VoIP test showed that operators in the COC could talk to those at Antenna Hill as 
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long as some type of network was set up there. For example, the mode of eommunieation 
between COC and Antenna Hill was via a switeh at Antenna Hill. Then, the DSU and 
eomputer eonneet to the switch to form the required network. This scenario could 
realistically have users on the same subnet. However, if communications were being 
established between two COCs, they most likely would be on different subnets. In 
conclusion, the DSUs need to be researched further to determine if they can be used when 
communicating between separate subnets. If they cannot, then the UOC units will be 
subject to a ‘flat’ network across multiple sites in order to employ VoIP through the 
DSU. 

With the use of VoIP phones within a network, the Marine Corps in the future 
could eliminate the need to employ switch-based equipment, such as the A/N TTC-42 or 
SB-3865. This will only happen though if the Marine Corps adopts some of these higher 
throughput technologies to provide inter-nodal communications because of the amount of 
bandwidth required by VoIP. Another option is to employ Coder-Decoders (CODECs) 
that reduce the size of the packets being sent for VoIP phone calls. 

Next, the KG-235 acts as a router but it cannot be programmed to run specific 
type of routing protocols. While the scenario for this testing allowed the authors to 
eliminate the network routers for the crypto devices, serious consideration needs to be 
given to the IP routing scheme for COC to COC connectivity and whether utilizing a 
routing protocol is important. The KG-235 would be sufficient for establishing encrypted 
traffic from the COC to Antenna Hill as the local unit easily controls the intra-nodal 
communications IP scheme. 

Finally, if the IMUX device can be packaged in a more effective manner for small 
on the move units, such as platoons, then this device can prove significant. Battalion and 
higher COCs will benefit from this device very little if smaller sized units do not have the 
capability of the Iridium channels. The battalion or higher COCs do not need this device 
to talk with higher headquarters as they will have much higher throughput means to 
communicate. 
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C. FIELD TEST #3 (RAYTHEON) 

1. Findings 

The findings discovered during Raytheon testing are discussed chronologically. 
The chronological order will consist of the baseline test, Lightpointe, SecNet-11, 
Ensemble, Terabeam, In-line Network Encryptor (INE), Radio Erequency Module 
(REM), MRV, MRV-REM Switchover, lEONA, Voice over Internet Protocol, Alvarion, 
and Iridium Inverse Multiplexer (IMUX). 

Eightpointe was the first company tested because they were a local company and 
were available to assist in the baseline testing. The baseline testing revealed it was going 
to be a challenge to communicate at a distance of 6.7 kilometers. The initial tests, data 
transfer test (SolarWinds) and Iperf, indicated about a 30 Mbps throughput across the 
network. It should be made clear that SolarWinds and Iperf are two diverse tests and 
their applications are dissimilar. SolarWinds was a program used to monitor throughput 
across the network. Iperf was a program that generated data across the network and 
displayed the results in a text file. In addition, SmartBits was used to generate data 
across the network and display the results in a spreadsheet. During the baseline testing, 
the SmartBits system changed the frame size while keeping the throughput constant. 
This SmartBits test indicated an overall average frame loss percentage of 4.37. The 
graphical representation of this test is represented in figure 34 (SMARTBITS 
RAYTHEON BASEEINE GRAPHICS). The other baseline product tested was SecNet- 
11. The two tests conducted while using SecNet-11 were SolarWinds and Iperf 
SolarWinds indicated an average throughput of 1.64 Mbps while Iperf had an average of 
1.3 Mbps. 

On Eebruary 3, the findings for Eightpointe indicated a steady link with zero 
percent packet loss. The average throughput for Eightpointe while using SolarWinds was 
27.5 Mbps, and the average throughput using Iperf was 35.8 Mbps. The disparity 
between SolarWinds and Iperf was due to the type of TCP fiow control protocols that are 
inherent in the TCP/IP network. According to Douglas Comer, fiow control is defined as 
“a protocol mechanism that allows a receiver to control the rate at which a sender 
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transmits data. Flow control makes it possible for a reeeiver running on a low-speed 
eomputer to aeeept data from a high-speed eomputer without being ovemm.”60 

SolarWinds demonstrated a stop-and-go flow eontrol meehanism being used in 
the network. The stop-and-go teehnique is an ineffieient teehnique to pass data aeross a 
network beeause it waits for an aeknowledgement from the distant eomputer that the 
distant eomputer is ready to reeeive the transmitted data.61 The throughput fluetuated 
when the type of data (Word, Power Point, Exeel, or Adobe doeuments) ehanged or the 
size of the file ehanged during the transfer data test. It was elear to see that the stop-and- 
go teehnique was being used between the two eomputers in order to prevent data overrun 
aeross the network. 

On the other hand, Iperf used what is ealled a sliding window teehnique for TCP 
flow eontrol. Aeeording to Comer, “the sender and reeeiver are programmed to use a 
fixed window size, whieh is the maximum amount of data that ean be sent before an 
aeknowledgement arrives.”62 The sliding window teehnique was observed with data 
eolleeted from the Iperf test. The type of data generated aeross the network by Iperf and 
by SmartBits was elean, steady, uniform data paekets sent at a uniform rate; therefore 
making it easier to apply the sliding window teehnique. The SmartBits data on 
Lightpointe revealed a throughput above 30 Mbps resulted in a frame paeket loss of 27.3 
pereent. During the SmartBits test, the frame size was kept eonstant and the size of the 
data being transmitted aeross the network was inereased by inerements of 10 Mbps. 
Exeeuting the SmartBits test was extremely diffieult at the beginning of the Raytheon 
test. The authors were inexperieneed in operating the software and the hardware. This 
resulted in the test eondueted during baseline testing being different from the test 
eondueted on the first day of testing. 

On Eebruary 3, unexpeeted low throughput was experieneed over SeeNet-11, 
whieh was not expeeted after having an impressive day of baseline testing. Antenna 

60 Douglas Comer, “Computer Networks and Internets with Internet Applications”, (Prentice-Hall Inc, 
New Jersey 2001, third edition), pg. 611. 

61 Douglas Comer, “Computer Networks and Internets with Internet Applications”, (Prentice-Hall Inc, 
New Jersey 2001, third edition), pg. 259 

62 Douglas Comer, “Computer Networks and Internets with Internet Applications”, (Prentice-Hall Inc, 
New Jersey 2001, third edition), pg. 259 
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wind loading had a tremendous effect on the results. The majority of the day was spent 
stabilizing the antennas in order to conduct the test. The distant end secured equipment 
on their end with guy wire in order to prevent the antenna from swaying. On top of the 
Raytheon building, an individual held the antenna and pointed the antenna in the 
direction of the distant end while the test was being conducted. The results from 
SolarWinds indicated a 540 Kbps maximum throughput. The throughput also varied 
depending on the type of data being transmitted. The Iperf test resulted in two very 
dissimilar results. The first run had an average throughput of 156.9 Kbps while the 
second run had an average throughput of 450.2 Kbps. The diverse results indicate the 
level of trouble the testers had in attempting to overcome antenna wind loading. 

The Ensemble test resulted in observing that an ATM network took time to 
configure and establish. The Iperf data averaged around the expected value of 28.9 
Mbps. The throughput monitored by SolarWinds indicated an average value of 5.96 
Mbps with zero packet loss. The outcome of the SmartBits data was to observe where 
the maximum throughput was located, to determine where SolarWinds was dropping the 
link, to measure the amount of packet loss when the throughput was doubled, and to 
examine the link with an over-saturation of data. The first run indicated a maximum 
throughput somewhere between 20 and 30 Mbps. The second run indicated that 
SolarWinds was showing the link down when the link was over-saturated with data. The 
problem was that the link was not down because VoIP was still operational over the link 
while the over-saturation was taking place. The saturation point was somewhere between 
30 Mbps and 40 Mbps. The data table did not reveal the exact saturation point. 
However, it did show the packet loss. SolarWinds has an upper threshold that if the 
packet loss is over 30%, then the link is identified as being down (this was a newly found 
inherent property that was discovered during this test). The data in the table below shows 
the packet loss over 30% at 33 Mbps, which is where SolarWinds identified the link as 
being down (Table 41). 
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Total 

30 

30 

48756 

37589 

11167 

22.9039 

Data Group 

N/A 

30 

47800 

36860 

10940 

22.887 

TEST Group 

N/A 

30 

956 

729 

227 

23.7448 

Total 

31 

31 

50388 

37593 

12795 

25.393 

Data Group 

N/A 

31 

49400 

36856 

12544 

25.3927 

TEST Group 

N/A 

31 

988 

737 

251 

25.4049 

Total 

32 

32 

51918 

37524 

14394 

27.7245 

Data Group 

N/A 

32 

50900 

36788 

14112 

27.725 

TEST Group 

N/A 

32 

1018 

736 

282 

27.7014 

Total 

33 

33 

53550 

37534 

16016 

29.9085 

Data Group 

N/A 

33 

52500 

36803 

15697 

29.8991 

TEST Group 

N/A 

33 

1050 

731 

319 

30.381 

Total 

34 

34 

55182 

37538 

17644 

31.9742 

Data Group 

N/A 

34 

54100 

36794 

17306 

31.9889 

TEST Group 

N/A 

34 

1082 

744 

338 

31.2385 

Total 

35 

35 

56814 

37405 

19409 

34.1624 

Data Group 

N/A 

35 

55700 

36668 

19032 

34.1688 

TEST Group 

N/A 

35 

1114 

737 

377 

33.842 

Total 

36 

36 

58446 

37552 

20894 

35.7492 

Data Group 

N/A 

36 

57300 

36806 

20494 

35.7661 

TEST Group 

N/A 

36 

1146 

746 

400 

34.904 

Total 

37 

37 

60078 

37559 

22519 

37.4829 

Data Group 

N/A 

37 

58900 

36831 

22069 

37.4686 

TEST Group 

N/A 

37 

1178 

728 

450 

38.2003 

Total 

38 

38 

61710 

37560 

24150 

39.1347 

Data Group 

N/A 

38 

60500 

36832 

23668 

39.1207 

TEST Group 

N/A 

38 

1210 

728 

482 

39.8347 

Total 

39 

39 

63342 

37567 

25775 

40.6918 

Data Group 

N/A 

39 

62100 

36850 

25250 

40.6602 

TEST Group 

N/A 

39 

1242 

717 

525 

42.2705 

Total 

40 

40 

64974 

37569 

27405 

42.1784 

Data Group 

N/A 

40 

63700 

36865 

26835 

42.1272 

TEST Group 

N/A 

40 

1274 

704 

570 

44.741 


FrameSize 

1518 






Throughput (% max load) 

40 






Frame Loss (%) 

42.17841 






Table 41. ENSEV 
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The third run was conducted to measure the amount of packet loss when the 
throughput was doubled. The run revealed that when the throughput was doubled, the 
packet loss increased. The data obtained from the SmartBits fourth run was an 
exaggeration of the third run. The goal for the fourth run was to see the link get over¬ 
saturated with data. The data table below demonstrates the link getting over-saturated 
(Table 42). 
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Total 

10 

10 

16218 

16218 

0 

0 

Data Group 

N/A 

10 

15900 

15900 

0 

0 

TEST Group 

N/A 

10 

318 

318 

0 

0 

Total 

20 

20 

32436 

32436 

0 

0 

Data Group 

N/A 

20 

31800 

31800 

0 

0 

TEST Group 

N/A 

20 

636 

636 

0 

0 

Total 

30 

30 

48756 

37590 

11166 

22.9018 

Data Group 

N/A 

30 

47800 

36860 

10940 

22.88703 

TEST Group 

N/A 

30 

956 

730 

226 

23.64017 

Total 

40 

40 

64974 

37568 

27406 

42.17995 

Data Group 

N/A 

40 

63700 

36850 

26850 

42.15071 

TEST Group 

N/A 

40 

1274 

718 

556 

43.64207 

Total 

50 

50 

81192 

37545 

43647 

53.75776 

Data Group 

N/A 

50 

79600 

36758 

42842 

53.82161 

TEST Group 

N/A 

50 

1592 

787 

805 

50.56533 

Total 

60 

60 

97512 

21164 

76348 

78.296 

Data Group 

N/A 

60 

95600 

20757 

74843 

78.28766 

TEST Group 

N/A 

60 

1912 

407 

1505 

78.71339 

Total 

70 

70 

113730 

21161 

92569 

81.39365 

Data Group 

N/A 

70 

111500 

20741 

90759 

81.39821 

TEST Group 

N/A 

70 

2230 

420 

1810 

81.16592 

Total 

80 

80 

129948 

21790 

108158 

83.23175 

Data Group 

N/A 

80 

127400 

21369 

106031 

83.22684 

TEST Group 

N/A 

80 

2548 

421 

2127 

83.47724 

Total 

90 

90 

146268 

21799 

124469 

85.09654 

Data Group 

N/A 

90 

143400 

21367 

122033 

85.09972 

Total 

100 

100 

162486 

1452 

161034 

99.10638 

Data Group 

N/A 

100 

159300 

1422 

157878 

99.10734 

TEST Group 

N/A 

100 

3186 

30 

3156 

99.05838 


1 FrameSize 

1518 






Throughput (% max loat 

100 






Frame Loss (%) 

99.10638 







Table 42. ENSEMBLE OVER-SATURATED 


The testing for Terabeam ineluded information about the optical scope, the auto 
tracking feature, and the easy setup. The optical scope was used to align the two lasers. 
The alignment process took a total of five minutes. The auto-tracking feature 
compensates for the swaying of buildings or the movement of the distant laser. The setup 
of the Elliptica was done quickly and efficiently. The findings provided the following 

















































insight when using the Iperf test: if the window size was too low, then the data 
throughput would result in a lower value. For instance, the two Iperf runs below 
demonstrate different throughput results by varying the window size of the send and 
receive buffers of the computers. The data below is a window size of 63 Kbytes: 


Client connecting to 192.168.1.2, TCP port 5001 
TCP window size: 63.0 KByte (default) 


[928] local 192.168.3.3 
[ ID] Interval 
[928] 0.0- 5.0 sec 
[928] 5.0-10.0 sec 
[928] 10.0-15.0 sec 
[928] 15.0-20.0 sec 
[928] 0.0-20.0 sec 


port 1068 connected with 192.168. 


Transfer 
34.0 MBytes 

26.2 MBytes 

27.3 MBytes 
28.0 MBytes 

116 Mbytes 


Bandwidth 
54.3 Mbits/sec 
42.0 Mbits/sec 
43.6 Mbits/sec 
44.8 Mbits/sec 
46.2 Mbits/sec 


1.2 port 5001 


Now when the data above was compared to a window size set at 0.1 Mbytes, the 
result was a bigger throughput for the Iperf test (see below for results). 


Server listening on TCP port 5001 
TCP window size: 0.1 MByte 


[920] 

[ID] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[920] 

[ 920 ] 


local 192.168.3.3 port 5001 connected with 192.168.1.2 port 1059 


Interval 

Transfer 

Bandwidth 

0.0- 1.0 sec 

8.7 MBytes 

69.7 Mbits/sec 

1.0- 2.0 sec 

9.8 MBytes 

78.4 Mbits/sec 

2.0- 3.0 sec 

9.7 MBytes 

77.4 Mbits/sec 

3.0- 4.0 sec 

10.7 MBytes 

85.3 Mbits/sec 

4.0- 5.0 sec 

10.2 MBytes 

81.3 Mbits/sec 

5.0- 6.0 sec 

9.5 MBytes 

76.3 Mbits/sec 

6.0- 7.0 sec 

10.9 MBytes 

88.3 Mbits/sec 

7.0- 8.0 sec 

10.9 MBytes 

87.2 Mbits/sec 

8.0- 9.0 sec 

11.3 MBytes 

90.2 Mbits/sec 

9.0-10.0 sec 

10.9 MBytes 

87.0 Mbits/sec 

0.0-10.0 sec 

10.3 MBytes 

82.1 Mbits/sec 
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As can be seen, adjusting the window size of the data being transferred was very 
important when condueting the Iperf test. Equally important were the results of 
SolarWinds. This test indicated that VoIP and video programs eould run in the 
baekground while data was transferred from one network to another. The average 
throughput while these tests were eondueted was 16.5 Mbps and the paeket loss observed 
was zero. Two runs using SmartBits were eondueted. The first run measured the data 
transfer between the two loeal area networks while the seeond run measured the data and 
VoIP transfer aeross the network. Both SmartBits tests were measured to a total 
throughput of 100 Mbps with an ineremental inerease of 10 Mbps. The frame loss for the 
data portion was 0.33 pereent, while the frame loss for the data and VoIP portion was 
0.37 pereent. 

The findings for the KG-235 Seetera In-Line Network Eneryptors (INE) were that 
the INE needed the latest firmware for higher throughput eapabilities and the authors 
were expecting a higher throughput result from the produet. When the INE was tested at 
Raytheon, the INE had an older version of firmware installed. The INE manufacturer 
speeifications rate the produet up to 17 Mbps aggregate data throughput.63 However, 
upgrades are being done in order to inerease throughput to 60 Mbps. The maximum 
throughput observed for the INE during testing was around 5 Mbps. The average Iperf 
throughput for the two runs while eonneeted to the Terabeam link was 3.6 Mbps. Later 
in the week, the INE was eonneeted to the ISONA link and the maximum Iperf 
throughput was 4.98 Mbps. While eonneeted to the Alvarion link, a BEOS produet, the 
average Iperf throughput was 2.4 Mbps. When the INE was eonneeted to the IMUX, an 
OTH produet, the average Iperf throughput was 7.7 Kbps. Thus, the throughput varied 
depending on the produet providing the link for the network. 

The Radio Erequeney Module (REM) produet eomes paekaged in a hardened ease 
to withstand a rugged military environment. The produet performed as expeeted as a 
series of tests were eondueted using an Iperf test, a data transfer test monitored by 
SolarWinds, and a SmartBits test. The average maximum Iperf throughput was 88.2 
Mbps, and the average maximum SolarWinds throughput was 40 Mbps. The SmartBits 

63 http://www.gdc4s.com/Products/secteraspecs.htm 
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test generated 20 VoIP phone eonversations going aeross the network along with 100 
computers passing information simultaneously across the network. The test showed less 
than 0.23 percent packet loss across the network as the load on the network was increased 
in 10 Mbps increments up to 100 Mbps. 

The findings for MRV were as expected. Even though the windy conditions 
presented a problem on top of the Raytheon building, the average maximum Iperf 
throughput resulted in 89.7 Mbps, and the maximum throughput recorded while using 
SolarWinds was 59 Mbps. During the SolarWinds test, there were runs where only data 
was being transferred, there were runs where VoIP was running in the background as data 
was being transferred, and there were runs where VoIP and video clips were being played 
as the data was being transferred. The SmartBits test consisted of 100 simulated 
computers sending data across the network along with 20 simulated phone conversations 
across the network. The test increased the throughput in 10 Mbps increments until the 
link reached 100 Mbps. SmartBits revealed a solid link with no packet loss for the test. 

The finding from the MRV-RFM Switchover, MRV’s OptiSwitch, was a seamless 
switchover between the REM and MRV’s Terescope. In order to capture the hand-off 
from one product to another, two tests were run simultaneously. The SmartBits test 
generated the data across the network while the SolarWinds test collected the nodal 
throughputs of the data being transmitted. The results recorded were a 54 Mbps 
throughput when the data was going across the FSO link and a 33 Mbps throughput when 
the data was going across the REM link. The hand-off was a seamless transition, as the 
user did not notice a break in the link. SmartBits revealed a fifty percent packet loss, 
which was expected because the FSO link had to be broken in order for the REM to pick 
up the link. 

The findings for tBONA were as expected. The maximum average Iperf 
throughput was 89.13 Mbps. The results from SolarWinds showed a maximum 
throughput value of 53 Mbps. During the SmartBits test, tSONA demonstrated the 
lowest frame loss percentage when compared to the other FSO companies. For the 
SmartBits test, 100 computers were simulated passing data across the network and 24 
phone conversations were simulated passing information across the network. From the 
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SmartBits results, ISONA demonstrated a frame loss pereentage of 0.0018 pereent. This 
low frame loss pereentage may be a result of ISONA’s laser being able to produee a 
power output of 640mW, a eonsiderable differenee over all other eompanies. IBONA's 
demonstration of a reliable link and of a produet that ean be integrated as a teehnieal 
solution for the next generation of wireless teehnologies highlights the endless 
eapabilities of wireless teehnologies. 

The findings for VoIP demonstrated that quality of serviee depended on how solid 
the link was between the sites, and VoIP remained operational aeross a degraded link. 
Quality of serviee was direetly proportional to the quality of the link. If the quality of the 
link was above average, then the quality of serviee for VoIP was the same. VoIP had a 
unique quality that was interesting. Due to the priority settings in the network routers, 
voiee was set for the highest priority, so VoIP was able to operate although the network 
was indieating a degraded status. When the quality of serviee was degraded, however, 
the phone eall was still operational. 

The findings for Alvarion were as expeeted for this BLOS produet. The produet 
has the eapability of operating in speeds of 6, 24, or 54 Mbps. The produet was tested 
with its integrated antenna and with a larger external antenna. The distanee of the testing 
was 6.7 kilometers through a metropolitan area over to a ridgeline. The Iperf throughput 
finding for the integrated antenna was 3.0 Mbps. The Iperf throughput finding for the 
external antenna was 4.2 Mbps, and the SolarWinds test indieated the throughput was 
4.92 Mbps. The SmartBits test revealed a throughput between 10-15 Mbps, with 
anything over 15 Mbps resulting in paeket frame loss over 22 pereent. When tested with 
the bulk eneryption, KG-235, the Iperf throughput was 2.4 Mbps. It is important to point 
out that in order for the authors to have aehieved a LOS link between the Raytheon 
building and the ridgeline on the Miramar base, the authors were required to plaee the 
produet being tested on top of Raytheon’s building. Alvarion’s produet was plaeed in 
Raytheon’s parking lot, whieh was not LOS to the distant ridgeline. 

The findings for the Iridium Inverse Multiplexer (IMUX) resulted in an average 
Iperf throughput of 7.7 Kbps. The IMUX has four satellite ehannels that are eapable of 
passing 2.4 Kbps on eaeh ehannel, resulting in a maximum throughput of 9.6 Kbps. The 
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nice feature of the IMUX was that the sender eould plaee a phone eall while 
simultaneously transmitting an image aeross the link. The eompression algorithm 
observed in the Mobile Researeh Faeility allowed several Mbyte pieture to be 
eompressed and sent over the Iridium link within seeonds. In addition, the sender eould 
cirele items of interest on the image that would not get eompressed in order to enhanee 
speeifie details of the images. 

The following paragraphs will discuss the Analysis portion of each product 
chronologically. 

2. Analysis 

The analysis of the baseline test indieated lower throughput levels than expeeted 
for the FSO produet. Expeeted values of the FSO produet were to be in the range of 80 
Mbps. The reason for the lower levels might have been due to a FSO produet being 
introdueed at a very long distanee. Another reason eould be that the baseline testing was 
eondueted in rainy eonditions. The rain might have eaused less than perfeet eonditions 
for the beam of light to traverse aeross to the distant site. On the other hand, the 
throughput levels for the 802.1 lb produet were higher than expeeted. The reason for the 
higher levels might have been due to more aecurate pointing of the parabolie antennas. 

The analysis of Lightpointe testing resulted in throughput values lower than 
expeeted. The authors ean only speeulate as to the reason why the maximum throughput 
was 35.8 Mbps. The reason may have been the distanee between sites, weather 
eonditions that day, alignment of the lasers, interfaee between the laser and the test bed, 
or configuration of the test bed. 

The author’s analysis of SeeNet-ll testing resulted in a better understanding of 
antenna wind loading. With a maximum throughput of 540 Kbps, it was obvious that a 
direetional antenna eould deliver a bandwidth that eould be benelieial in a taetieal 
environment even in adverse weather eonditions. In addition, SeeNet-II is a seeure 
National Seeurity Agency (NSA) Type 1 and FIPS-140 eompliant eneryption deviee. 

The analysis for Ensemble indicated that an ATM network took time to eonfigure 
and establish. In addition, the ATM network handled the transfer of voiee, data, and 
video extremely well until the link beeame over-saturated. Ensemble’s 802.16 product 
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provided a reliable link with limited bandwidth when eompared to FSO. The produet 
performed as expected with Iperf, while SmartBits had greater throughput results than 
SolarWinds. The reason for the lower throughput in SolarWinds was that flow control 
was being handled twice, once through the ATM protocols and again through flow 
control measures in the computers sending and receiving the data. 

The analysis for Terabeam resulted in throughput values that were expected from 
an FSO product. The most impressive observations were the optical scope, the auto 
tracking, and the easy setup. The data collected was a strong indicator that an FSO 
product could be used to connect different sub-systems for CAC2S. As long as the sub¬ 
systems were within line-of-sight, an FSO product like Terabeam’s Elliptica could be 
used to pass data from one site to another. 

The analysis for the KG-235 Sectera In-Line Network Encryptors (INE) indicate 
that the product has a tremendous potential for encrypting commercial off-the-shelf 
wireless products. The maximum throughput for the INE was around 5 Mbps. In order 
to produce a higher throughput from the product, the authors discovered that the latest 
version of firmware needed to be installed on the INE. The throughput from each 
product was different. The ESO products were able to produce a higher throughput 
whereas the OTH product produced the lowest throughput. Along with the KG-235, 
other encryption devices provide bulk encryption for optical networks. The KG-189 
could be used for increased throughput levels. According to SPA WAR, “the KG-189 
program currently consists of models supporting three standard Synchronous Optical 
Network (SONET) data rates: OC-3 model operates at 155 Mbps, OC-12 model operates 
at 622 Mbps, and the OC-48 model operates at 2.5 Gbps.”64 However, the author’s 
analysis revealed that the throughput was directly correlated to the bandwidth of the 
product being tested. In addition, each INE was assigned a different subnet in order for 
the two networks to communicate with each other. In order to pass information from one 
network to another, the laptops had to be configured on the same subnet as the INE. 


64 

https://infosec.navy.mil/ps/?t=infosecprodsservices/infosecprodsservices.tag&bc=/infosecprodsservices/bc 

_kgl89.html 
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The analysis for the Radio Frequeney Module (RFM) resulted in throughput 
values as expeeted from the produet. The field engineers were able to configure the 
switch (provided with the RFM), to speed 100 and full duplex. This product would be a 
great fit for the sub-system connectivity in CAC2S. 

The analysis for MRV resulted in values that were expected from a FSO product. 
MRV’s Terescope performed extremely well in windy conditions. The stability on top of 
Raytheon’s building initially presented a problem, which was solved by securing the laser 
optical stands. MRV’s impressive reliability indicated that an FSO product could be 
utilized in an intra-nodal CAC2S environment. 

The analysis for MRV’s OptiSwitch resulted in much higher than expected 
performance. The seamless transition indicated that a component such as the MRV’s 
OptiSwitch can be a vital element in an architecture that requires multiple technologies to 
operate simultaneously. In addition, a similar technology that has both RF and FSO 
embedded, such as MRV’s Terescope Fusion, could potentially be the solution for an 
amalgamation of different technologies. 

The analysis for ffiONA resulted in data throughput levels that were expected. 
The power output for iEONA was higher than the other products tested which might have 
contributed to a lower frame loss percentage produced by iEONA. iEONA demonstrated 
that the LOS link was capable of passing a maximum throughput in the high 80’s with 
outstanding reliability. 

The analysis for VoIP indicated that the quality of service is not necessarily 
dependent on the quality of the link. This is to say that once the link has reached its 
maximum throughput level, the quality of the phone call degraded to the point of 
dropping the call. Once the call was dropped, the link was no longer operational. During 
one of the testing runs, the link became degraded but the phone call remained operational. 
The phone call remained intact because of the priorities that were established in the 
network’s routers and because the phone call was placed over an IP based network, VoIP 
link. 

The analysis for Alvarion indicated this type of product, a BLOS product, could 
be used in a metropolitan area for connectivity. Alvarion’s Orthogonal Frequency 
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Division Multiplexing (OFDM) product showed a throughput that was capable of passing 
through power lines, buildings, and trees over a distance of 6.7 kilometers. Different 
types of antennas exist for this product. The scenario the equipment needed to address 
would determine the type of equipment used for an application. In addition, this product 
was tested in the Camp Roberts experiment in March. The product’s testing in March 
demonstrated additional range characteristics and it also demonstrated communications 
on-the-move. 

The following paragraphs discuss the Findings and Analysis of Field Test #4, 
Camp Roberts experiment. 

D, FIELD TEST #4 (CAMP ROBERTS) 

The following findings and analysis are provided to help further understand the 
results of the testing event conducted at Camp Roberts. The following topics are covered 
in the respective order: Mobile Access Router (MAR), Cisco 2950 switch between 
routers, Cisco 3550 switch, network module on Cisco 3745 router, Lightpointe, 
Terabeam, ISONA, Linksys 802.11a access points, VoIP, OFDM, tethered balloon, 
UAV, Segovia/Omega Systems, INMARSAT, Communications on-the-move, and IP 
based network. 

1. Findings 

The students intended to use the MAR as the key piece of equipment at the NOC, 
POP, MRC #1, and MRC #2. This router is the size of one’s hand and would have 
allowed the students to integrate multiple technologies at one location and still effectively 
route traffic throughout the network. While the cards of this router are made by Cisco, a 
company called Western DataCom integrated the cards. The main problem encountered 
with the MAR was the configuration settings, which enable each router to communicate 
with one another. Despite the inability to employ the router during the testing event, LT 
Manny Cordero continued to pursue getting the router to function properly. During an 
NPS driven experiment in May at Camp Roberts, CA, the MAR showed its usefulness as 
Western DataCom representatives and LT Cordero finally put the configurations 
together. The setup in May was very similar to the student’s testing in March. The MAR 

worked much like a Cisco Call Manager where all the phones communicated back to the 
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server. For the MAR, a Home Agent was plaeed within the network and the rest of the 
MARs throughout the network talked baek to the Home Agent. In May, the students 
were also able to see the MAR automatieally switeh between two teehnologies when one 
was degraded. These technologies were employed at the same time in a point-to-point 
scenario. Furthermore, the connections to the MAR that performed Layer 3 functionality 
were RJ-45 and smart serial. 

On 8 March, the students inserted a Cisco 2950 switch between the two routers at 
the POP site. They did this in order to connect the OFDM and FSO links as well as to 
provide a LAN at the POP. While this setup worked, it was not the most desirable 
configuration. However, it was the only option for the equipment the students had on- 
hand. A computer connected to the switch in the LAN was configured for a gateway of 
192.168.3.1 to communicate with MRC #1. To talk with the NOC, the gateway was set 
at 192.168.3.2. Therefore, separate computers at the POP were used to talk throughout 
the network, or one computer switched its gateway depending on the intended direction 
of communication. 

In order to expand on the results acquired on 8 March, the students were able to 
attain a Cisco 3550 switch on 9 March, which was a Layer 2/3 capable device. This 
enabled the students to have one device handle the functions that took two routers and 
one switch the day prior. Specific ports on the 3550 switch were configured for the 
appropriate IP address of each subnet. However, the students were not able to enter an IP 
routing protocol into the Cisco Internetwork Operating System (lOS) for the switch. All 
of the other routers were using EIGRP. This meant that every device in the network that 
had routing capabilities needed to be manually told where to route. EIGRP would have 
automatically routed the traffic to the appropriate place as it learned what devices were 
around it. The manual routing statements in the Cisco lOS worked properly, but the 
students encountered problems getting to the MRC #1 site on that particular day. One of 
the problems could have been the routing statement in the Cisco 3550 switch to get to the 
MRC #1 site. Another problem could have been from Segovia’s satellite link. They 
needed to tell their headquarters every IP address of the routers and 3550 switch in the 
network, and how each of these devices were expected to route. A mistake could have 

been made when configuring the satellite settings. 
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On 10 March, the students experimented with putting a 16-port Ethernet switeh 
network module on the back of the 3745 router, whieh was loeated at MRC #1. The 
intent was to determine if the ports on the module were layer 3 eapable. If so, this would 
have assisted the students in having one device with enough ports that could handle 
802.11b and OFDM links as well as a LAN. Unfortunately, the ports eould not be 
eonfigured for Layer 3. 

On 11 Mareh, MRC #1 was in a similar situation as the POP site on 8 Mareh. 
Two routers needed to be eonnected together through a switeh in order to have two 
teehnologies at the site (802.11b and OFDM) and a LAN off the switeh. This 
suceessfully worked as the computer eonneeted to the switeh at MRC #1 had a default 
gateway of 192.168.7.2 in order to oommunieate with the POP and NOC. To talk with 
MRC #2 the eomputer was set for a default gateway of 192.168.7.1. 

Next, Lightpointe and Terabeam provided the two FSO li nks (Mareh 8-9). While 
no data was sent over the FSO link, data was obtained from the NOC to MRC #1 via the 
POP site. Throughput readings on Iperf showed throughput of 4-5 Mbps on average. 
The best throughput reading on Iperf between the NOC and POP using OFDM was 12 
Mbps. This data was then routed through the POP switeh and through the FSO link head 
to another network. Based on testing experienee, eaeh network setup drops the 
throughput eapabilities of a link by 10 -20%, whieh was most likely the eause of the drop 
from 12 Mbps to 4-5 Mbps. 

ISONA’s produet did not establish eonneetivity during this testing event due to 
problems with the media eonverters. Reviewing the issue a week after the testing, it was 
realized that the media eonverters that INONA used at Camp Roberts were the 
MC102XL's, whieh are multi-mode eompatible. These units were NPS-owned and 
provided to ILONA for their use. At the time, the students did not know there were two 
types of media eonverters (single and multi-mode eapable). The ones that ILONA used 
in past field-testing events with the SONAbeam-155M were MC103XL's, whieh are 
single-mode eompatible deviees. The mix up of media eonverters was the eause for the 
FSO link being down. 
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The students originally intended to use the Linksys WAP55AG 802.11a aeeess 
points in bridge mode to eonduet point-to-point communieations. However, after 
attempting to eonfigure them, the students determined that this eould not be 
aeeomplished. The Linksys WAP 11 aeeess points, similar to the WAP55AG, that were 
used on the balloon and UAV eould be eonfigured for bridge mode. Therefore, the 
students did not expect to run into this finding. Since the WAP55AGs could not go into 
bridge mode, the students employed them in the LANs to allow laptops to connect 
wirelessly. 

While using the VoIP telephones, 7960G and 7940G, the students determined that 
a specific protocol needed to be used by all the phones within the network as well as the 
Call Manager server. The Cisco Call Manager Skinny Client Control Protocol (SCCP) 
was employed for this purpose. An example of the differing protocols happened with the 
7960G phones that were on temporary loan from Cisco. The two phones that arrived at 
NPS were each loaded with a different protocol, SGCP and SIP, and they could not 
communicate with each other. Furthermore, VoIP calls were made over the 
Segovia/Omega Systems satellite link, through multiple technologies, and through the 
tethered balloon. The calls over the tethered balloon proved troublesome since the link 
was unstable. The reason that a stable link is needed is that the phones throughout the 
network need continuous contact with the Call Manager server. 

The OFDM technology proved most impressive during this testing event. 
Whether Alvarion or Redline was using their equipment to communicate over hills, 
through trees, or on the move, the technology definitely proved reliable. Since the signal 
being used was broken up into multiple carriers rather than a single carrier, the chances of 
getting connectivity increased tremendously. The OFDM technology equipment used by 
Alvarion and Redline is Layer 2 capable, thus an IP address is assigned to either the 
indoor unit for Alvarion or the AN-50 box for Redline. Furthermore, the distance 
capability of OFDM is out to about 20 kilometers depending on the antenna used. The 
students had seen it work out to 10 kilometers in a separate testing event. 

The tethered balloon was one of the platforms available during this event to 
provide retransmitted communications. While working with the balloon, the students 
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developed many eoneems in employing this platform in a military environment. First, 
the reliability of getting the balloon airborne is of question. The balloon eould not fly in 
bad weather such as high winds and heavy rain. When it was flying in winds above 10 
knots, the balloon moved enough to cause significant packet loss of greater than 20% 
with a directional antenna employed on the ground. This leads the authors to recommend 
a ground-tracking antenna be employed on land to maintain connectivity with the 
balloon. Omni-directional antennas could be an option, but the gain on the antenna has to 
be enough to reach the distance. The packet loss encountered during the testing was 
enough to cause the network to be down for a significant amount of time. Finally, the 
balloon caused air traffic control issues. The UAV had to be deconfiicted with it by 
distance and time. If for some reason the location of a tethered balloon did not get passed 
to the air control agencies and pilots, there could be serious problems with helicopters 
and UAVs flying through the tethered line. 

While the UAV did not meet its mission as an airborne communications relay for 
this testing event, a great deal of learning occurred with airborne and ground antennas. 
First, the placement of the antenna on the UAV needs to be tested extensively in order to 
obtain the best radiation pattern results. In addition, omni-directional antennas need 
certain sized base plates in order to maximize the radiation patterns. On the wooden 
platform that was attached to the UAV, the antenna was located on the side of the board 
and it was placed through the platform. This did not allow for signals to radiate out of 
the antenna in an optimal manner. Regardless of the orientation of the antenna, it needed 
to have a base plate of the appropriate size for the antenna. Furthermore, the antennas on 
the ground need to be either omni-directional or tracking. The omni-directional antenna 
needs to have enough gain or amplification to reach the UAV. A tracking antenna will be 
optimal as long as GPS coordinates could be constantly fed to the antenna from the UAV. 
This type of antenna allows for a more directional beam to be sent to the UAV antenna. 

The Segovia/Omega Systems team was able to configure their satellite system to 

provide a satellite link within a private network established by the students. Segovia did 

this by communicating to their headquarters the network scheme and how traffic needed 

to be routed. Therefore, the students were able to use the airborne satellite as a relay 

station between the NOC and POP. This did not seem to be a normal mission performed 
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by Segovia, since they normally provide phone and Internet services. However, the 
Segovia/Omega Systems team showed their diversity in the type of services they could 
provide to their customer. The throughput they provided was 256 Kbps on 9 March and 
up to 1 Mbps on March 10-11. Furthermore, after being exposed to their mounted 
satellite system on the truck, Segovia/Omega Systems proved to be a solid possible 
solution for the CoNDOR POP vehicle satellite system. 

During the testing, the students were able to see how well Nera’s INMARSAT 
link performed on-board a moving vehicle. The satellite antenna was very easy to mount 
and keep stable while employed on the vehicle. Since Nera’s modem was unable to 
interface with the private network established by the students, they could not incorporate 
their satellite link into the network. However, Nera did state they could do this with the 
right assets. On the other hand, Nera was able to show the capabilities of their Internet 
and phone services while on the move. The throughput was only 64 Kbps, but Nera did 
state they are developing a 256 Kbps link. 

Communications on-the-move proved to be challenging for numerous reasons. 
For example, mounting the equipment onto the different vehicles created some difficult 
scenarios for the research team. Wooden platforms were used to mount tripod stands, 
which incorporated OFDM antennas and omni-directional antennas for the tethered 
balloon and UAV. The Nera satellite terminal was also mounted on a wooden platform. 
Some innovative HMMWV mounting options have already been addressed in the Marine 
Corps Signals Intelligence community. The HMMWV has a radar device mounted on 
top of the vehicle (just above the area where the driver and passenger sit). A satellite 
system could be mounted in the same area. In addition, this vehicle has an antenna 
mount that attaches to the frame of the vehicle just next to the passenger door. 
Implementing concepts such as these can make communicating on the move more 
feasible for military personnel. 

This testing event demonstrated the advantage of an IP based network. This type 
of network allows any IP based technology to plug-and-play anywhere within the 
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network. In addition, several teehnology methods were evaluated in this testing event in 
order to communicate BLOS and OTH to include OFDM, the tethered balloon, the UAV, 
and Broadband satellite. 

2. Analysis 

The MAR could effectively be employed with any of the programs studied in this 
research; UOC, CAC2S, and CONDOR. For UOC and CAC2S, the MAR could be 
employed as a means to route traffic in an intra-nodal situation where two wireless 
technologies are used in a redundant manner between COC and Antenna Hill for the 
UOC and between PDS, SDS, and CS sites for CAC2S. The MAR could also be utilized 
for inter-nodal communications for UOC and CAC2S nodes that displace quite often. 
The units that stay stationary probably should use regular network routers, such as the 
Cisco 3745 used in this testing experiment. Furthermore, the MAR would be especially 
useful at the CoNDOR POP vehicle. This site will be managing multiple nodes and 
multiple technologies. The only dilemma for the MAR could be the types of connections 
from the multiple radios the Marine Corps uses. 

Despite the unfavorable setup of a switch between the two routers at the POP, the 
results yielded from the 8 March experiment show the diversity of a network 
configuration. IP traffic can flow in a variety of ways as long as one has the imagination 
to make it happen. On the other hand, an easy solution to this situation would be to have 
a router that possesses a sufficient amount of Ethernet ports for the scenario. For the 
POP, the router would have needed three ports: one for the FSO link, one for OFDM, 
and one for the LAN. 

The author’s concluded that the Cisco 3550 switch was not the appropriate device 
for the POP site in order to handle multiple connections. Even though the switch is Layer 
3 capable, it did not perform like a regular Cisco router. A solution to the problem could 
be to use the Cisco 3745 router with its two East Ethernet ports that come with the router. 
In addition, a 2EE-2W-V2 network module could be inserted into the back of the router 
to give an extra two East Ethernet ports. If more ports are needed, the router is capable of 
receiving multiple network modules to provide the amount of ports desired. 
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The 16-port Ethernet switeh network module used on the router at MRC #1 was 
Layer 2 eapable only. Thus, an IP address eould not be assigned to the port. While it is 
eonvenient to have a router and a switch on one device, the cost of the module is more 
expensive than a regular Cisco 2950 24-port switch. 

Again, the Cisco switch between the routers at MRC #1 on 11 March was a 
solution based on availability of equipment. The easiest solution would have been to 
insert a two-port Fast Ethernet module (2FE-2W-V2) into the Cisco 3745 router to give 
the router four Fast Ethernet ports. 

When Lightpointe and Terabeam were set up at MRC #1, they were providing a 
link between that site and the POP. The test results demonstrated that the slowest link in 
the network dictated the data throughput of the other links. Since OFDM was limited to 
12 Mbps between the NOC and POP, the FSO link between the POP and MRC #1 did not 
speed up the data transfer when communicating from the NOC to MRC #1. The data was 
transferred at the rate of the OFDM link, since the two links were connected in series. 

The mix-up with the ffiONA media converters made it evident to the research 
team that having the correct media converter available could determine whether a 
positive or negative outcome could be achieved in a testing experiment. The two types of 
media converters mentioned in the analysis section above looked exactly the same, so the 
difference between the two was not evident. This was one more reason why running 
fiber cable between the FSO link head and the network router is more beneficial. The 
other reason is that throughput can be increased. 

The WAP55AGs are Linksys products, a lower end variant of Cisco equipment. 
Neither Cisco or Linksys access points can do NSA certified Type-1 encryption, but they 
can do AES or Triple DES encryption. A determination needs to be made whether DoD 
is willing to accept AES or Triple DES encryption within a wireless LAN. If so, then the 
Cisco or Linksys products are viable options within the LAN. 

Cisco IP phones can change protocol loads, but one phone cannot have more than 
one protocol loaded onto it at any given time. The most appropriate protocol for the 
scenario needs to be accomplished prior to starting an operation. The VoIP phones 
performed poorly with the 25-50% packet loss that was being experienced through the 
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tethered balloon when it was relaying 802.11b signals. If VoIP calls were made the 
routing priority on the network routers, the chance of maintaining the call was much 
greater. 

OFDM technology is a good fit for UOC and CAC2S in an intra-nodal scenario. 
This technology allows antennas and other communications equipment to be put in 
valleys where the gear can be camouflaged more effectively. In addition, wires do not 
need to be run over long distances. OFDM is also effective over long distances for inter- 
nodal communications. Even if two nodes are located outside the range of a point-to- 
point link, OFDM can be retransmitted to increase the distance. The difference in 
retransmitting is that there is increased flexibility of the placement of the antenna, and 
there is no longer the need to put it on top of a hill. This technology can also be used in a 
Military Operations in Urban Terrain (MOUT) environment since it works around 
buildings. Furthermore, OFDM can be used while on the move. This allows for 
connectivity within a convoy of vehicles that need to exchange video, voice, and data. If 
a UAV is flying overhead providing information to one of the vehicles in the convoy, 
then that vehicle can easily pass the information to the others via OFDM. The convoy 
can also maintain whatever security posture deemed necessary because OFDM 
communications does not limit the spacing of the vehicles. 

The tethered balloon cannot be relied on to provide tactical communications. It 
presents security issues by giving away friendly positions, and it is too dependent on 
weather conditions. In addition, the logistics of getting helium bottles and a heavy launch 
platform around the battlefield are key concerns in adapting this platform for tactical 
communications. 

The UAV is a more realistic method of relaying communications on the 
battlefield. The platform used from MLB Company was quiet and very hard to detect 
while airborne. As long as these platforms can remain stealthy, they can provide a 
powerful tool for communicators in the Marine Corps. With the Pioneer being the only 
Marine Corps UAV, there will be major problems when tasking this aircraft for 
communications missions rather than reconnaissance. However, the platform can 
perform a dual role when applicable since an airborne communications payload could 
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remain relatively lightweight. If the Pioneer was not an option, the Marine Corps eould 
look at future generation UAVs to be outfitted with a eommunieations relay package on 
board. Additionally, the Marine Corps could look at outfitting other aircraft such as the 
C-130 with an airborne relay package. The C-130 that flies the Direct Air Support Center 
missions can loiter over the battlefield for 12 hours at a time. 

For the Segovia/Omega Systems team, a challenge will be how much the services 
will cost the Marine Corps. The advantage that Segovia/Omega Systems possesses is that 
they have proven that they can work their satellite system into a private Marine Corps 
battlefield communications architecture, and they can provide the required Internet 
connectivity for the NIPRNET and SIPRNET. If VoIP is implemented into the 
communications architecture, then the Marine Corps can provide phone services 
internally and they do not need to rely on Segovia for this service. Finally, 
Segovia/Omega Systems can be utilized in the UOC, CAC2S, and CoNDOR 
communications architecture. They have a small footprint, minimal power requirement, 
and a powerful ability to provide broadband satellite connectivity. 

With the Marine Corps command centers struggling to maintain connectivity 
while on the move, Nera’s INMARSAT satellite link offers a possible viable solution. 
When UOC or CAC2S units send forward elements out, the forward echelon can keep 
their common operational picture up-to-date which allows for an easier and quicker 
displacement. One disadvantage to the INMARSAT services is that it is very expensive. 
Thus, further cost-benefit analysis is needed. 

To communicate on the move, vehicles need to be outfitted with the proper 
mounts to place the antennas. OFDM antennas can be reduced in size to provide 
connectivity while on the move. For example, in May Redline offered to try six-inch 
antennas with their equipment for a demonstration to Special Operations Command. 
Furthermore, MRC vehicles already have antenna locations on the back of the vehicle 
that can be used while on the move. Thus, these vehicles could be outfitted with the 
appropriate antenna to maintain connectivity with an airborne relay platform. 

Overall, this testing evolution was conducted to show how a CoNDOR 
architecture could look with currently available commercial technologies. This research 
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event also direetly applied to the UOC and CAC2S programs as they eontinue to look for 
innovative methods to eommunieate between and within nodes. 
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IV. CONCLUSIONS 


The Marine Corps is developing new eommand and eontrol systems such as UOC 
and CAC2S, and new concepts for Marine Expeditionary Forces to bridge the gap 
between Major Subordinate Commands (MSC) and their subordinate units. If the Marine 
Corps continues to rely on legacy communications for these programs, they could fall 
short of meeting the information needs of the next war. New technologies, such as the 
ones evaluated in this research project, should be seriously considered to keep the 
warfighter one step ahead of the enemy. The authors looked at UOC, CAC2S, and 
CoNDOR and how to improve line-of-sight (LOS), beyond line-of-sight (BEOS), and 
over-the-horizon (OTH) communications for these programs. 

The ultimate goal of this research project was to introduce different technologies 
that could offer more flexibility, mobility, and capability at the tactical level compared to 
current legacy equipment. These new technologies could provide the Marine Corps with 
a tactical wireless edge, which could prove to be essential in the future combat missions. 
To address the issues of the UOC, CAC2S, and CoNDOR programs, the authors 
conducted four field tests. Field Test One was used to familiarize the students with 
networking, data collection, and develop interactions with commercial vendors. Field 
Test Two through Four then addressed the issues of the different programs mentioned 
above. The combination of all the field tests enabled the authors to become better suited 
to draw the following overall conclusions for each program. 


A, UOC 

The planned intra-nodal connectivity between COC and Antenna Hill for the 
UOC system will be via fiber optic cable. Furthermore, the inter-nodal communication 
between UOCs will be via MRC-142, satellite communications, or LOS radios. The 
inter-nodal connectivity needs to be explained further due to the different levels of COCs. 
First, the battalion level COC, called CapSet IV (see Chapter I for further information), 
is still relying upon LOS and UHF SATCOM radios to talk to senior and subordinate 
units. Division and regimental level COCs, called CapSet II and III (see Chapter I for 
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further information) respectively, are using the MRC-142, satellite communications, and 
LOS radios to communicate with senior and subordinate units. The Marine Corps 
understands the vulnerabilities of relying on LOS radios and MRC-142 vehicles for data 
and voice connectivity. During Operation Iraqi Freedom (OIF), the Marine Corps 
regiments and divisions relied much more on satellite communications to maintain 
connectivity since LOS equipment was outran. Consequently, alternative methods need 
to be pursued instead of running cable in intra-nodal scenarios and using LOS equipment 
for inter-nodal communications. Several viable commercial technologies were examined 
in this thesis that warrant further evaluations for UOC use. 

The following technologies were examined for potential use in the UOC intra- 
nodal scenario (COC to Antenna Hill): FSO, Microwave, OFDM, 802.16, and 802.11b 
over SecNet-ll. The FSO, Microwave, and 802.16 equipment evaluated did not have 
any encryption built into the products. Both OFDM companies were capable of limited 
encryption that was built into the equipment. The Harris SecNet-11 gear utilizing 
802.11b is certified for Type 1 encryption, but the SecNet-11 testing did show a 
significantly lower throughput than all the other technologies (1-2 Mbps). This may be 
enough to support the battalion level (CapSet IV) setup, however further testing needs to 
be conducted to verify this. 

When using the KG-235 with the FSO, Microwave, and OFDM products, the 
throughput only reached up to 5 Mbps. However, this was due to the firmware load on 
the KG-235. The KG-235 is capable of sending data up to 60 Mbps. The authors were 
unable to assess 802.16 with the KG-235 due to time limitations. All of these 
technologies are viable wireless means in the intra-nodal setup. The inherent problem 
with using the bulk encryptors is the cost of having to employ two (one at each end) of 
the wireless equipment. While units can save time, be more flexible, and enjoy more 
safety, the cost of the wireless equipment and encryptors could outweigh the benefits. 

In the inter-nodal scenario, CapSet IV units are planned to rely upon current LOS 
radios such as EPLRS and SINCGARS to exchange data with subordinate units when 
UOC is fully fielded. This research did bring to light many alternatives that can be 
explored for more effective communications. The Joint Tactical Radio System (JTRS) 
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will in effect alleviate some of the current throughput limitations, but that program is still 
several years away from being implemented. There is currently no need for an abundant 
amount of bandwidth at the lower levels, but the information age has no boundaries. And 
therefore it is ideal that units at even the lowest level have video and imagery capabilities. 
As a result, high throughput technologies that were examined could be packaged more 
appropriately for units on-the-move and in manpack size devices to provide the 
throughput capabilities to receive large files in an expedient manner. For example in 
LOS situations, FSO, Microwave, and OFDM equipment can be packaged into one 
carrying case that can be set up within minutes. OFDM technology is the most versatile 
as it can be used anywhere throughout the battlefield in LOS and BLOS scenarios and 
with any size units. 

For CapSet II and III, the need for equipment that can be set up and torn down in 
an expedient manner became more and more prevalent during OIF. BLOS and OTH 
technologies ruled the battlefield as units outran LOS communications. While most units 
relied upon Blue Force Tracker to maintain situational awareness on-the-move and 
SMART-T for satellite connectivity while stationary, this research showed other options 
available that could significantly improve the abilities of units to maintain the Common 
Operational Picture on-the-move and exchange data more rapidly when communicating 
COC to COC. INMARSAT showed its versatility and reliability while employed on-the- 
move. It can attain throughput rates up to 64 Kbps with improvements possibly reaching 
256 Kbps. Broadband satellite services can reach almost five times the throughput of 
SMART-T’s capabilities. However, the cost of employing these technologies can be 
expensive, and this may warrant a cost-benefit analysis for future studies. 

An alternative method to communicate between COCs is to utilize airborne assets 
to retransmit signals across large distances. Several technologies can be used to 
accomplish this task, yet the equipment and antenna need to be small enough to be 
employed on the aircraft. In this research study, 802.11b was retransmitted and the 
equipment was inherently small enough to put in an airborne package. OFDM would be 
a viable option to put airborne but the distance remains in question because the signal 
may not be able to be amplified. 
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Due to the security issues of wireless communications between COC and Antenna 
Hill, the Marine Corps may be reluctant to go wireless since fiber cable can provide high 
throughput and is a secure means of transferring data. However, General Dynamics is 
recommending a technology insertion to the UOC program to pursue a possible wireless 
connection between COC and Antenna Hill. Next, the ability to talk BLOS/OTH is 
becoming more and more of a priority for the Marine Corps. The UOC CapSet II and III 
will benefit most from the Broadband satellite, OFDM, and aerial relays evaluated in this 
research as means to supplement or replace the MRC-142 vehicle for LOS 
communication and SMART-T for OTH situations. INMARSAT and Iridium 
technologies may be the answer of choice for communications on-the-move. 


B. CAC2S 

The present plan for CAC2S is to connect the intra-nodal sites by heavy-duty 
fiber optic cable. In order to provide redundancy, all the sites would be connected with 
fiber in a token-ring fashion. However, the setup could still be vulnerable since it relies 
on the cumbersome and time-consuming tasks of laying and burying wire. On the other 
hand, fiber allows the transmission of secure data due to the inherent security of data 
being contained within the fiber. As wireless technologies are studied for potential use in 
an intra-nodal scenario, decision makers need to be aware that the data is now in the open 
and must be encrypted with a device that is comparable to sending data through the fiber. 
A bulk encryptor can accomplish this, much like the KG-235 used in this research, or the 
wireless equipment would need security built into it. 

The following technologies were examined for potential use in the CAC2S intra- 

nodal scenario: FSO, Microwave, OFDM, 802.16, and 802.11b over SecNet-11. FSO, 

Microwave, and 802.16 equipment evaluated did not have encryption built into the 

products. For the OFDM equipment, Redline Communications has 64-bit encryption 

built-in and Alvarion is capable of AES encryption. NSA certifies the Harris SecNet-11 

gear utilizing 802.11b for Type 1 encryption, but SecNet-11 testing did show a 

significantly lower throughput than all the other technologies (1-2 Mbps). When using 

the KG-235 with the FSO, Microwave, and OFDM products, the throughput only reached 

up to 5 Mbps. However, this was due to the firmware load on the KG-235. It is capable 
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of reaching 60 Mbps with the right firmware load. Due to time constraints, the authors 
were unable to assess 802.16 with the KG-235. 

The current CAC2S inter-nodal structure uses a combination of MRC-142 and 
TRC-170 systems. The MRC-142 is strictly LOS with a maximum throughput of 576 
Kbps and the TRC-170 can extend out to 100 miles with a maximum throughput of 4.6 
Mbps. Since there are not enough TRC-170s for each node located throughout the 
battlefield, MRC-142s are employed with retransmission sites set up on top of hills or 
mountains when LOS cannot be attained. The MRC-142 and TRC-170 already employ 
wireless means between sites, so the research conducted by the authors looked for 
wireless technologies that could significantly increase the throughput between CAC2S 
sites while also minimizing the physical footprint. 

Several technologies were looked at for a CAC2S inter-nodal setup since there 
can be LOS, BLOS, and OTH requirements in this scenario. This all depends on the 
terrain, location, and movement of the CAC2S units. The technologies examined were 
FSO, Microwave, OFDM, 802.16, and 802.11b over SecNet-ll. Each of these 
technologies was successfully tested at 6.7 kilometers. FSO was more challenging to 
align due to the narrow laser beam transmitted. Microwave, OFDM, 802.16, and 802.1 lb 
over SecNet-11 (amplified) demonstrated the potential to reach long distances if LOS 
was maintained. 

When evaluating BLOS technology, the authors reviewed OFDM. These 
products can reach out to approximately 20 kilometers in a BLOS scenario, while 
demonstrating the ability of communicating over hills, around buildings, and through 
trees. This technology changes the dimensions of inter-nodal communications because 
units could possibly eliminate the need for a retransmission site. In addition, tremendous 
flexibility on antenna placement is attained. 

INMARSAT and Broadband satellite were evaluated for their OTH capability. 
INMARSAT throughput capability is too small for CAC2S inter-nodal use, but it could 
be effective when CAC2S nodes start to displace and need to maintain connectivity on- 
the-move. The broadband satellite capability could reach up to 9 Mbps and its footprint 
is considerably less than the TRC-170, so it does have serious potential to replace or 
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augment the TRC-170 for use within the CAC2S arehiteeture. Both INMARSAT and 
Segovia’s Broadband satellite serviees are eapable of NSA Type 1 eneryption. 

All of these teehnologies (FSO, Mierowave, OFDM, 802.16, 802.11b over 
SeeNet-11, Broadband satellite, and INMARSAT) have a limited power draw of less than 
20 Watts, whieh means that the equipment ean draw power off a generator that is 
providing support to other gear. The MRC-142 and TRC-170 always eome with their 
own generators, thus making the footprint larger. While work remains to be done to 
ensure that these wireless teehnologies are eompatible within a military environment, 
these eommereial options improve throughput, minimize footprints, and require less 
power. All of these eharaeteristics eertainly would improve the way CAC2S deploys to 
the field. Reeommendations for the CAC2S program ean be found in the next ehapter. 


C. CONDOR 

The problem inherently in the CoNDOR setup is that legaey LOS radios and 
eventually JTRS are being relied upon to provide data eonneetivity down to the lower 
levels. These are all limited in throughput capabilities. For example legacy radios 
provide less than 56 Kbps of throughput and JTRS is below 2 Mbps. While the 2 Mbps 
throughput is sufficient, JTRS will not be fielded until 2008 and beyond, and it is an 
unproven concept. The satellite communications being considered to connect the POP 
vehicle to higher headquarters is also limited in throughput (around 1 Mbps). Several 
LOS and BLOS technologies evaluated in this research are viable options to connect the 
CoNDOR POP vehicle to subordinate units. In addition, several technologies were 
evaluated to connect the POP vehicle to senior units in a BLOS or OTH scenario. 

The CoNDOR scenario covers the whole range of communication scenarios, 
LOS, BLOS, and OTH. Squads, platoons, companies, and battalions maneuver so 
quickly that they could be in any of these communication situations within minutes. 
Thus, an integrated architecture needs to be adapted where all the nodes connecting to the 
POP can talk with each other, ensuring continuous connectivity with the POP at battalion 
headquarters. This type of architecture is currently very difficult to achieve with the 
legacy radios employed, since all of them currently rely upon LOS. If a communications 
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architecture can be developed similar to Field Test Four, then units can take advantage of 
reliable connectivity and increased throughput from the new technologies. This can be 
done while on-the-move and when traversing over hills, between buildings, and through 
trees. OFDM and airborne relays are two key technologies that can transform 
communications for ground units on the battlefield, since the technologies do not require 
stringent LOS. 

Connectivity from the POP vehicle to higher headquarters in the CoNDOR 
scenario will most likely happen via satellite, although if close enough, BLOS scenarios 
may apply. The Broadband satellite services by Segovia/Omega Systems should be 
seriously considered for possible use on the CoNDOR POP vehicle. The equipment can 
be mounted on the vehicle and is versatile as far as network employment. Private 
network connection, Internet, and phone services can all be provided. Alternate means of 
connectivity from the POP vehicle to higher headquarters can be achieved through 
airborne relay methods. The platform can either relay directly between the two sites, or 
the platform can relay the signal into space where it can enter the satellite ring and be 
routed to any location in the world. This is a much more complicated scenario as there 
are several points of failure in the air as well as on the ground. If the POP vehicle is 
within 20 kilometers of its higher headquarter, most likely a regiment, then the OFDM 
technology can be employed, eliminating the need for expensive satellite services. 

Many lessons can be learned from OIF as the Marine Corps outran their LOS 
radios. As CONDOR evolves and is adopted by the Marine Corps, those same tactical 
radios that failed to provide connectivity in OIF may again be insufficient for the 
CoNDOR scenario. As the Marine Corps continues to find ways to utilize existing 
equipment, this research opens doors to proven commercial off-the-shelf technologies 
that the military can further examine. If OFDM is packaged correctly for the appropriate 
sized units, then this technology can truly integrate units and be a reliable source to 
connect to the POP vehicle. Employing the technology airborne could further enhance 
the potential of ConDOR. The price of employing OFDM is fairly reasonable, but the 
need for encryption may drive up the cost. Whatever the cost may be, this technology 
could revolutionize communications in the Marine Corps. 
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Since the use of wireless equipment introduees a potential security problem to 
DoD infrastructure networks, DoD Direetive 8100.2 was published on 14 April 2004 to 
address these issues. The eneryption of unclassified data for transmission to and from 
wireless devices is required. Data eneryption must be implemented end-to-end over an 
assured ehannel and shall be validated to meet the requirements of FIPS PUB 140-1. 
This applies to all eommereial wireless deviees, serviees and teehnologies ineluding both 
voiee and data eapabilities that inelude eommereial wireless deviees eapable of storing, 
proeessing, or transmitting information.65 Furthermore, Marine Administrative 
(MARADMIN) message 032/2004 was released on 23 January 2004 based on guidanee 
from the DoD Chief Information Offieer. This MARADMIN stated that all Marine 
Corps information technology developed, aequired, or procured would be IPv6 eapable. 
This is to help the Marine Corps transition to IPv6 by 2008 in order to aehieve net-eentrie 
operations and other warfare goals. In addition, this will help to minimize eosts during 
the transition period from IPv4 to IPv6.66 

Based on guidanee from DoD Direetive 8100.2, the need for encryption becomes 
a serious coneern as eommereial technologies are embraeed by the military. Since most 
eommereial off the shelf teehnologies are not equipped with Type 1 eneryption, separate 
deviees need to be used to enerypt the traffie going through eommereial deviees. This 
raises the costs of procuring new equipment, so a eost-benefit analysis needs to be done 
to determine if the eapabilities of the gear eompared to legaey equipment outweigh the 
eosts of proeuring the gear. Some of the eompanies do have eneryption teehniques built 
into their products such as AES, but further analysis needs to be done to verify that this 
meets the standard to transmit elassified traffic. Overall, a requirement eould be given to 
a eommereial eompany to pursue building Type 1 eneryption into their produets. In turn, 
this eould signifieantly raise the eost. 

As seen in MARADMIN 032/2004, Marine Corps networks will follow the IPv6 
standard by 2008. This reinforees why the students chose to demonstrate a fully IP based 
network in all testing events. The UOC and CAC2S programs are also pursuing IP based 

65 DoD Directive 8100.2, “Use of Commercial Wireless Devices, Services, and Technologies in the 
Department of Defense (DoD) Global Information Grid (GIG)”, 14 April 2004. 

66 MarAdmin 032/2004, “Marine Corps Internet Protocol Version 6 (IPv6) Policy”, 23 January 2004. 
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networks for their systems. There are numerous benefits of being IP based that the 
students identified during this researeh. First, voiee, video, and data ean all be sent over 
this one protoeol. This ensures a eommon standard aeross the network in whieh 
information ean be easily shared among all users. During Field Test Four, the students 
were able to demonstrate multiple teehnologies aeross eight subnets. These teehnologies 
were eompatible as long as the equipment supported an IP network. This allowed for a 
tremendous amount of flexibility for new teehnologies that eould be interfaeed in a 
CoNDOR seenario. In addition, if the UOC and CAC2S use VoIP phones and laptops to 
move away from switeh-based equipment for telephones, a much smaller footprint for 
each node would be required. Furthermore, CoNDOR will benefit tremendously if every 
device used to transfer data can be assigned an IP address. 

In conclusion, the authors introduce different technologies that offer more 
flexibility, mobility, and capability for communications on the tactical battlefield. 
Throughout this research study, the focus revolved around testing equipment and network 
configurations in an IP network in order to demonstrate a tactical wireless edge. Special 
consideration was given to wireless issues for the UOC, CAC2S, and CoNDOR, which 
could improve line-of-sight, beyond line-of-sight, and over-the-horizon communications 
for each program. These new technologies will transform communications in the United 
States Marine Corps for the 2U* century. 
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V. RECOMMENDATIONS FOR UOC, CAC2S, AND CONDOR 


A. WHAT CAN BE IMPLEMENTED NOW 

Initial guidance from Marine Corps Systems Command was to examine 
teehnologies that eould be implemented into UOC, CAC2S, and CoNDOR ‘now’ as well 
as in the future. For the ‘now’ portion of the write-up, the authors decided to eombine 
the UOC and CAC2S reeommendations sinee the eommand and eontrol systems have 
similar distanee requirements when physieally deployed on the battlefield and the 
requirements for eommunieations on-the-move are also very mueh alike. CoNDOR’s 
reeommendations were kept separate sinee it is not a eommand and eontrol system but 
rather a eoneept of eonneeting multiple eehelons of eommand together. Table 43 below 
is a quiek referenee guide summary of reeommendations for the three programs. For 
UOC and CAC2S, there are four functional areas that communications requirements can 
fall under: intra-nodal, inter-nodal, eommunieations on-the-move, and aerial relay. The 
CoNDOR eoneept revolves around the Point of Presenee Vehiele (POP-V) so the 
funetional areas were outlined as follows: into POP-V, out of POP-V, oommunieations 
on-the-move, and aerial relay. 

The ranking system used to prioritize the reeommendations for each type of 
eategory (line-of-sight (LOS), beyond line-of-sight (BLOS), and over-the-horizon 
(OTH)) within the physieal strueture breakdown of the programs is straightforward. The 
number “one” depiets the first reeommendation out of all the teehnologies. Eaeh 
subsequent number up to five delineates the seeond, third, fourth, and fifth 
reeommendations. Rank s were assigned subjeetively by the authors based on the results 
of the tests, the requirements of the systems, and the author’s experienee. 
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Table 43. UOC, CAC2S, AND CONDOR RECOMMENDATIONS 


1. UOC/CAC2S 

a. Intm-Nodal 

By utilizing wireless technologies to link a Command Center to Antenna 
Hill within a UOC node or from Processing and Display Subsystem (PDS) to 
Communications Subsystem (CS) and Sensor Data Subsystem (SDS) in a CAC2S node, 
the Marine Corps could potentially replace fiber cables that run between the sites. This 
will enable a quicker setup and tear down of equipment, which would then enable a unit 
to be more flexible and mobile. In addition, the possibility of cables being damaged by 
vehicles and equipment would be eliminated, and Marines would not have to spend time 
digging trenches to bury fiber cable as they do now. 

The intra-nodal setup is divided into two different categories for 

communications, LOS and BEOS. While antennas will most likely sit in some type of 
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defilade, the wireless eommunieations equipment eould be easily plaeed on top of the hill 
to obtain LOS with the COC or PDS for UOC and CAC2S respeetively. Sinee another 
teehnology was explored in this researeh that would allow eonnectivity to be established 
while the two antennas were not in sight of eaeh other, there is the BLOS eonneetivity 
reeommendation for the intra-nodal seenario. 

The LOS teehnologies researehed for the intra-nodal setup in the order of 
reeommendation are as follows: Free Space Optics (FSO), Microwave, Orthogonal 
Frequency Division Multiplexing (OFDM), 802.16, and 802.1 lb over SecNet-11. FSO is 
the right fit for a short distance of less than 2 kilometers. There are various benefits to 
using this technology: throughput comparable to fiber cable speeds, operates in a license 
free spectrum, enjoys a quick set up and tear down time, and is not as susceptible to 
weather at a short distance. While the Microwave product. Radio Frequency Module, 
examined for this thesis had comparable characteristics to the FSO product with better 
distance capabilities and less vulnerability to atmospheric conditions, it required a license 
to operate in the 14-15 GHz range. This would not be an issue during a time of war, but 
when training with it throughout the world there could be problems obtaining frequency 
use. In addition, the transmitting beamwidth is much greater than FSO; therefore, 
making microwaves more susceptible to interception. Next, OFDM and 802.16 have less 
throughput capability than FSO and Microwave. OFDM can operate in the 5 GHz 
license free spectrum and has limited built in encryption, while 802.16 requires a 
frequency license to operate the equipment. Finally, 802.11b over SecNet-11 has a 
powerful capability of National Security Agency (NSA) certified Type 1 encryption built 
into the cards. Therefore, no external encryption device would is needed to utilize this 
equipment. The downside of the SecNet-11 equipment is that the throughput of 802.1 lb 
is severely limited compared to the other broadband technologies. The 1-5 Mbps attained 
would not be enough to replace a cable run between sites, which can currently run at 
gigabit speeds. 

OFDM was examined and evaluated throughout this thesis research at 

various field tests. OFDM has a distinct advantage of being placed in valleys near 

Antenna Hill, where it can be camouflaged without inhibiting the capacity of the link. 

The throughput of the technology can vary considerably, but it is capable of reaching up 
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to 72 Mbps. The authors only saw throughput up to 24 Mbps, however, when in non- 
line-of-sight situations. A signifieant benefit of this equipment is that it is small and 
requires minimal power. The 20-30 Mbps range would be sufficient to support the link 
between Command Center and Antenna Hill for the UOC and CAC2S. Even though this 
was the only technology examined for BEOS situations, no other technologies are known 
that can offer this type of flexibility unless satellite communications are employed. The 
use of satellites would not be practical for the intra-nodal scenario. Therefore, OEDM is 
the only recommended BEOS technology for both UOC and CAC2S in the intra-nodal 
setup. 

b. Inter-Nodal 

The UOC program will continue to utilize legacy systems to provide 
connectivity between UOC nodes located throughout the battlefield. At the regiment, the 
MRC-142 vehicle can provide EOS connectivity. Below the regiment level, tactical 
radios such as Enhanced Position Eocation Reporting System (EPERS) and Single 
Channel Ground-Air Radio System (SINCGARS) will continue to be utilized until the 
Joint Tactical Radio System (JTRS) is fielded. At the regiment, for BEOS and OTH 
capability. Secure, Mobile, Anti-Jam, Reliable Tactical Terminal (SMART-T) will be 
employed as well as receive only Global Broadcasting Service. There is currently no 
BEOS/OTH capability below the regiment except for PSC-5 UHE SATCOM radios. 
Next, CAC2S will rely on two primary methods of transmitting data between nodes on 
the battlefield, MRC-142 and TRC-170. Despite their capabilities, these legacy systems 
have some shortfalls. The MRC-142 has limited bandwidth with EOS distance 
capabilities of up to 35 miles, and the TRC-170 has a major footprint to go along with a 
significant power requirement. The technologies examined can provide significant 
improvement in throughput, a smaller footprint, and a smaller power requirement over 
the legacy equipment planned for employment with UOC and CAC2S systems. 

Since the distances between UOC and CAC2S nodes are unpredictable 
due to the frequent movement of units on the battlefield, the three communications 
scenarios, EOS, BEOS, and OTH, could all be encountered at any given time. The LOS 
scenario is rated quite different that the LOS setup for intra-nodal communications. In 
order of ranking, the following technologies are recommended for use in LOS situations 
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for the inter-nodal scenario: OFDM, 802.16, Microwave, FSO, and 802.11b over 
SecNet-11. When LOS can be attained between two UOC/CAC2S nodes, it is likely the 
distance will be greater than 5 kilometers and the terrain will not be perfectly flat. 
OFDM is best suited for this type of setup since it is the most forgiving of the 
technologies if ideal LOS is not attained. The reason to recommend 802.16 technology 
over Microwave is that 802.16 can reach out to 20 kilometers while the high throughput 
microwave is limited to 13 kilometers. Next, FSO is designed for distances of less than 
five kilometers. While it was shown to function up to seven kilometers and most likely 
further than that with ideal weather conditions, bad weather would reduce the quality of 
communications obtained at further distances. 802.11b over SecNet-11 is recommended 
last because of its low throughput as distances increase, and it is vulnerable to denial of 
service since it operates in the well known 2.4 GHz range. 

OFDM can operate in LOS or BLOS situations. This makes the 
technology the number one recommendation for inter-nodal BLOS scenarios. OFDM can 
maintain connectivity over hills, through trees, and around buildings. In addition, the 
cost to purchase the equipment is under $5k, which makes it relatively inexpensive. No 
other technologies were examined that could provide terrestrial BLOS connectivity; 
therefore, satellite connectivity was rated against OFDM in the BLOS category. The 
second, third, and fourth recommendations are as follows: Broadband satellite, 
INMARSAT, and Iridium respectively. These are also in the same order for OTH 
communications in the inter-nodal scenario. Broadband satellite provided by 
Segovia/Omega Systems can replace the TRC-170 setup for CAC2S with its capabilities 
to reach up to 9 Mbps, and it is comparable in size with the SMART-T system but could 
provide more throughput capability for the UOC node. INMARSAT and Iridium are 
ranked lower because the throughput capabilities for the inter-nodal setup are insufficient 
to support the requirement for the nodes. INMARSAT is also much more expensive than 
Broadband satellite. These two technologies will be discussed in the communications on- 
the-move section when they are more applicable. 
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c. Communications on-the-Move 

Communications on-the-move can no longer be overlooked for the UOC 
and CAC2S nodes sinee forward echelons must be sent out when displaeing. This 
forward eehelon is used to taking eontrol when the main node begins to displaee. While 
the forward eehelon is displaeing, they need to keep situational awareness to assist in the 
turnover from main to forward. This situational awareness usually eomes in a digital 
format. So, if eonneetivity is lost then vital time eould be wasted trying to pass updates 
from the main to the forward eehelon. Communications on-the-move is broken down 
into three eategories whieh are listed as follows: within the eonvoy, outside the eonvoy, 
and short/long halts. 

(1) Within the Convoy. The eommunieations that are utilized 
within the eonvoy link all the vehieles together to exehange information. One vehiele 
within the eonvoy will maintain eonneetivity with other units outside the eonvoy. Single- 
ehannel voiee oommunieations are eurrently maintained but data eonneetivity is quite 
limited. If a limited network is set up within eaeh vehiele, and eaeh is outfitted with the 
appropriate antennas, then the whole convoy can maintain high throughput connectivity 
via OFDM or 802.11b over SeeNet-11. OFDM has the highest reeommendation since 
LOS does not need to be maintained while the vehicles are moving. Eaeh vehiele ean 
remain a safe distanee away from the others, whieh ensures a good seeurity posture. The 
OFDM technology can connect the eonvoy by plaeing a sector antenna in the lead vehicle 
while all others maintain an omni-direetional antenna (other options eould be employed). 
802.11b over SeeNet-11 ean work as long as LOS is sustained while the vehieles are in 
motion. Most likely omni-direetional antennas and amplifiers would need to be utilized 
for this purpose. The eost for both of these setups would be very similar. 

(2) Outside the Convoy. While the distance and terrain ean vary 
greatly when eommunicating from a forward eehelon eonvoy baek to the main, some type 
of satellite eonneetivity that can function on-the-move would be needed. INMARSAT 
and Iridium were examined for this eapability. INMARSAT’S throughput eapabilities are 
far superior to the limited throughput of Iridium. Therefore, INMARSAT is 
reeommended over Iridium despite the lower eost of Iridium. If within a 10-20 kilometer 
radius, the eonvoy eould maintain eonneetivity with the main terrestrially through the use 
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of OFDM. The antennas on the vehiele and with the main would need to be omni¬ 
directional, which would decrease the distance OFDM could operate. OFDM is the last 
recommendation due to the distance limitation, but it is still an option since terrain 
becomes less of an issue with this technology. 

(3) For Short/Long Halts. While communications on-the-move is 
vital, it is also important to recognize that there may be times when short or long halts of 
a convoy are needed. Thus, some type of quick setup is needed for connectivity from the 
forward echelon to the main. The communications within the convoy can stay per the 
recommendations earlier, as vehicles can maintain an effective security posture and stay 
BLOS from each other. If the convoy was using INMARSAT as the communications 
connectivity for on-the-move, then this may remain sufficient for a short halt. However, 
during a lengthy halt, it may prove useful to set up Broadband satellite connectivity for 
more throughput capability. The Segovia/Omega Systems equipment can self-acquire the 
aerial satellite; therefore, connectivity could be established within minutes. 
d. Aerial Relay 

The use of aerial relays for UOC and CAC2S nodes can greatly increase 
inter-nodal communications. This could be an alternative to the MRC-142 or TRC-170, 
as the 802.1 lb over SecNet-11 could be retransmitted via the aerial platform for hundreds 
of miles if the signal was amplified and appropriate antennas were utilized. If it is 
determined that OFDM can be amplified, then distance could equal that of 802.11b and 
greater flexibility is attained on where antennas would need to be placed on the ground to 
maintain connectivity with the aerial platform. Since 802.1 lb was tested and has proven 
to work over great distances, this technology is the first recommendation. More research 
needs to be conducted with OFDM to determine the validity of using it as a technology in 
an aerial relay platform. 

2. CONDOR 

a. Into POP-V 

The current plan for the CoNDOR scenario is to place a Point of Presence 
Vehicle (POP-V) at the battalion level to further enhance the capabilities of the 
subordinate units with low throughput capabilities. This vehicle will allow those units 
with EPLRS, SINCGARS, HF, HF Automatic Link Establishment (ALE), and UHE 
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SATCOM to have access to Major Subordinate Commands (MSCs) through the satellite 
connectivity at the battalion level. While this research looked at transformational 
communication technologies for the UOC and CAC2S, these type of scenarios are mostly 
stationary with the need to connect a relatively large node. For the CoNDOR scenario, 
the situation is much more unique as units could be stationary one minute and on-the- 
move the next. In the traditional structure of a battalion, the company headquarters may 
be stationary long enough to incorporate what is recommended for the UOC and CAC2S 
program. Thus, the LOS recommendations for the communications into the POP-V 
resemble the LOS rankings used for UOC and CAC2S. Since EPLRS is currently the 
best form of data connectivity down to the lower levels at 56 Kbps, it is obvious that the 
technologies recommended would bring a new kind of capability down to the lowest 
level. The following technologies are recommended for LOS into the POP-V in the order 
of preference: FSO, Microwave, OFDM, 802.16, and 802.1 lb over SecNet-11. 

The first recommendation for LOS communications is to use FSO, which 
has a throughput capability ranging from T1 (1.5 Mbps) up to Gigabit speeds (1000 
Mbps). The setup is scalable to the size of the unit, and the time to establish connectivity 
with the POP-V could be within minutes. The microwave product examined can also 
vary the data rate from T1 (1.5 Mbps) but only up to OC-3 speeds (155 Mbps). This 
setup is more cumbersome to the user and frequency licensing is an issue during 
peacetime. Next, OFDM is a relatively quick and simple setup. The throughput 
capabilities are much more limited compared to the other technologies (up to 72 Mbps), 
but OFDM is much more effective in BLOS situations when compared to the other 
technologies. 802.16 could be a nice fit communicating into the POP-V as it can provide 
connectivity in a 360-degree range, but it is limited to less throughput than OFDM at 
roughly 66 Mbps. Finally, 802.11b over SecNet-11 is much more flexible in the 
changing environment from stationary to mobile, and it has Type 1 encryption built in. 
The equipment also creates a small footprint, but the throughput is limited to 1-5 Mbps 
depending on the strength of the signal. 

For BLOS situations when communicating from the lower echelons to the 

POP-V, the following technologies are recommended in order of preference: OFDM, 

Broadband Satellite, INMARSAT, and Iridium. OFDM can become the technology of 

200 



the future for the Marine Corps if it can be properly encrypted in a cost effective manner. 
The ability to communicate over hills, through trees, and around buildings can allow the 
subordinate units communicating with the POP-V to maintain an effective security 
posture while still achieving high throughput capabilities up to 24 Mbps. Broadband 
satellite connectivity can be packaged in a suitcase size unit, but the cost of using the 
services at such low echelons may be unrealistic. INMARSAT and Iridium provide no 
greater increase in throughput over the current LOS radios, but they do offer the 
flexibility to talk BLOS/OTH. 

b. Out of POP- V to MSC 

When communicating from the POP-V to an MSC, the scenario will most 
likely require some form of BLOS or OTH connectivity. The distance is unpredictable 
enough that some form of satellite connectivity is needed at this site to attain the required 
communications to the MSC. INMARSAT or some form of TACSAT can provide that 
connectivity, but the Marine Corps is looking for commercial products that can augment 
this need. During the various field tests, the authors were fortunate enough to be exposed 
to several leading technologies that can be applicable for the POP-V to MSC 
requirement. In a BLOS situation, the following technologies are recommended in the 
order of the authors preference: OFDM, Broadband satellite, INMARSAT, and Iridium. 
OFDM can provide a terrestrial connection up to 20 kilometers and can reach over hills, 
through trees, and around buildings. This technology can also be retransmitted if the 
situation dictates. The next three technologies. Broadband satellite, INMARSAT, and 
Iridium, were also ranked in the same order for OTH capability. 

Segovia/Omega Systems Broadband satellite connectivity during Field 
Test Four was most impressive. They are able to vary the amount of throughput that is 
needed and can provide private network capabilities, Internet services, and phone 
services. Their link can also be Type 1 encrypted, which could provide SIPRNET 
connectivity. INMARSAT can be employed while stationary, but the cost is just not 
comparable to what other service providers can offer when stationary. Iridium has a low 
throughput of up to 9.6 Kbps when combining four Iridium channels. It is recommended 
last because of the throughput. However, the technology is currently available, as 
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evidenced by its use at the Marine Corps Warfighting Lab for the Expeditionary Tactical 
Communications System. 

c. Communications on-the-Move 

(1) Within the Convoy. Communications on-the-move is what the 
CoNDOR architecture is built for. Since current LOS radios can communicate on-the- 
move, transformational communications needs to be able to replicate this functionality. 
In order to improve throughput within a convoy of vehicles, which in the CoNDOR 
scenario may be a company or platoon convoy, several technologies were evaluated for 
applicability at this level. The recommendations resemble those that were made for UOC 
and CAC2S since the technologies can be used at any level. The following are the 
recommendations in order of priority: OFDM, 802.11b over SecNet-11, and Iridium. 
OFDM will again provide sufficient bandwidth for a platoon/company sized unit, enable 
a small footprint, and allow vehicles flexibility on where to locate in a convoy. 802.1 lb 
over SecNet-11 offers similar benefits but LOS must be maintained between the vehicles. 
This is the main reason it is ranked second behind OFDM, despite the encryption 
capabilities of SecNet-11. Innovative methods can be explored to encrypt the OFDM 
link in a cost effective manner. Finally, Iridium is recommended as the third option for 
this scenario due to its capability to be used on-the-move, and it could provide a small 
sized unit in a convoy with a sufficient amount of bandwidth. 

(2) Outside the Convoy. This category is most applicable to how 
units will maintain connectivity with the POP-V while on-the-move. If there is a 
company or platoon size unit that is traveling in a convoy, then they need to have some 
means of maintaining connectivity to the POP-V in order to be connected with all other 
units associated with that POP-V. Again, this mirrors the communications on-the-move 
section for UOC and CAC2S. INMARSAT is the first recommendation due to the on¬ 
board satellite terminal’s ability to track the aerial satellite while in motion. This is 
currently a costly solution, but Marine Corps Systems Command is exploring options to 
have users share the bandwidth, which in turn would reduce the cost. The second 
recommendation is to use Iridium due to its being available now and the ability to use it 
an unlimited amount. In addition, it can be used on-the-move and from anywhere on the 
battlefield to talk back to the POP-V. The down side is that the throughput offers no 


202 



more than the eurrent existing LOS radios. Lastly, OFDM is reeommended for 
eommunieations with the POP-V while on-the-move beeause of its capability to maintain 
connectivity over adverse terrain conditions. On the other hand, the distance OFDM can 
traverse is roughly 20 kilometers without a retransmission site. This is the reason for 
ranking it last when compared to INMARSAT and Iridium. 

(3) For Short/Long Halts. As units maneuver throughout the 
battlefield in convoys, there will be times when the convoy will make a short or long 
halts that produce opportunities to establish connectivity while stationary. This then 
turns into the BLOS scenario that was explained earlier for communications into the 
POP-V. If within distance of a POP-V, then the number one choice remains OFDM due 
to its inexpensive cost and unique capabilities. The second, third, and fourth 
recommendation all depend on satellite communications. These are all going to be more 
costly, although Broadband satellite could be packaged for smaller units. It can also 
provide a sufficient amount of bandwidth for a small unit at a justifiable cost. 
INMARSAT connectivity could possibly allow multiple users to share the 64 Kbps 
currently offered. If upgrades are accomplished as expected, then there will be more 
bandwidth to share. Iridium will offer a means to communicate that is already paid for, 
but the throughput offers no more than the LOS radios. However, Iridium does offer 
BLOS/OTH voice and data connectivity. 

d. Aerial Relay 

The use of aerial relays for CoNDOR can greatly increase the ability to 
communicate from units to the POP-V and from the POP-V to MSCs. This could be an 
alternative to relying on LOS radios or satellite communications. The two technologies 
examined in this thesis are recommended for use in the aerial relay platform, 802.11b 
over SecNet-11 and OFDM. 802.1 lb over SecNet-11 can be retransmitted via the aerial 
platform for hundreds of miles if the signal is amplified and appropriate antennas are 
utilized. If it is determined that OFDM can be amplified, then distance can equal that of 
802.11b and greater flexibility is attained at the locations where antennas would need to 
be placed on the ground to maintain connectivity with the aerial platform. Since 802.1 lb 
was tested and has proven to work at various distances, this technology is the first 
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recommendation. More research needs to be conducted with OFDM to determine the 
validity of using it as a technology in an aerial relay platform. 

Several commercial off-the-shelf technologies were examined to 
determine if they could be implemented into the UOC, CAC2S, and CoNDOR programs 
within the next few years. Based on this research, the authors developed their 
recommendations for each program. The research team decided to combine the UOC and 
CAC2S recommendations since the command and control systems have similar distance 
requirements when physically deployed on the battlefield and the requirements for 
communications on-the-move are very much alike. CoNDOR was kept separate since it 
is not a command and control system, but rather a concept of connecting multiple 
echelons of command together. Table 44 below was developed by the authors to assist 
them in making the recommendations for each of the programs. It lists the pros and cons 
of the technologies that were examined, and recommends how each technology should be 
employed in the communications scenario (LOS/BLOS/OTH). Table 44 below was the 
driving factor that assisted the authors in deciding on the recommendations displayed in 
Table 43 above. 



FSO 

LOS 

Fiber throughput speeds, quick setup time, 
operates in license free spectrum 

Susceptibie to weather conditions, 
short distance (< 5 km), iaser aiignment 

MICROWAVE (RFM) 

LOS 

Up to OC-3 speeds, aiready packaged, 
reaches out to 13 kiiometers 

Obtain authorization for frequency use, 
susceptibie to interception due to RF use 

802.16 

LOS 

Adaptive moduiation, up to 66 Mbps, 

360 degree coverage out to 20 km 

No buiit-in encryption, company evaiuated was 
ATM based (there are others IP based) 

802.11b over SecNet-11 

LOS 

Type 1 encryption buiit-in, 
send up to secret ievei data, smaii footprint 

Low throughput of 1 -2 Mbps, difficult to configure, 
not compatible with other 802.11 b 

OFDM 

BLOS 

Communicates over hiiis, through trees, and 
around buiidings, 25 Mbps throughput 

Limited encryption built in, 
need good azimuth for BLOS connectivity 

BROADBAND SATELLITE 
(Segovia/Omega Systems) 

BLOS/OTH 

Large throughput capabiiities of up to 9 Mbps, 
mountabie on a vehicie. Type 1 encryption 

Annual/Monthly Fees, but not by minute 

INMARSAT 

(Nera) 

BLOS/OTH 

Sateiiite connectivity on-the-move, 
smaii mountabie vehicie piatform, encryption 

Expensive per minute fees, 
low throughput of 56 Kbps (working on upgrades) 

IRIDIUM 

BLOS/OTH 

Capabie of combining four channeis, 
comms on-the-move, no monthiy fees 

Low throughput of 2.4 Kbps per channel, 
difficult to send data without compression 


Table 44. PRO/CONS OF EACH EXAMINED TECHNOLOGY 
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B, WHAT CAN BE IMPLEMENTED IN THE FUTURE 

The future holds many possibilities regarding what could be implemented on the 
tactical battlefield. In order to meet DoD’s commitment to Joint Vision (JV) 2020, laser 
communication will most likely be the leading technology because of its high throughput 
capability. JV 2020 outlines full-spectrum dominance and network centric warfare, but 
without lasers that vision is only a dream. In addition, technologies such as 
Transformational Satellites, Wideband Networking Waveform, Joint Tactical Radio 
System; and concepts such as Bandwidth Sharing, Quality of Service, and a Joint 
Integrated Common Operating Picture are critical in a network centric environment. 
Many efforts are being employed in order to fully develop the Transformational 
Communications Architecture (TCA). In the following sections three recommendations 
will be described for the UOC/CAC2S/CoNDOR scenarios, a wireless recommendation 
will be described in a FORCEnet scenario, and follow-on research recommendations will 
be discussed. 

1. UOC/CAC2S/CoNDOR 

a. UA VLaser Communication 

Utilizing aerial relay for communications has proven to extend 
connectivity on the tactical battlefield. The idea of dedicating a UAV for this service is 
something decision-makers will have to address in the near future. Similar to how aerial 
relays currently operate, it is proposed for a futuristic transformational communications 
network that UAV laser communications be utilized in order to enhance the maximum 
throughput on the tactical battlefield. 

The concept consists of a UAV with laser equipment working as a relay 
into the satellite TCA that will exist in 2015 and beyond. Inside the UAV, there will be 
several lasers that will have the ability to track moving objects. The laser that is oriented 
to the sky would be responsible for tracking, sending, and receiving information from the 
satellite unit. The laser that is oriented laterally would be responsible for tracking, 
sending, and receiving information from other aerial units. The laser that is oriented to 
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the ground would be responsible for traeking, sending, and reeeiving information from 
the ground unit. Utilizing the UAV this way allows it to beeome an integral part of the 
TCA. 

UAV laser eommunieations is a definite option for future 
UOC/CAC2S/CoNDOR communications. The suggested application, described above, 
for the UAV employing laser connectivity among the units on the tactical battlefield can 
potentially be achieved within the next two decades. A diagram illustrating power to the 
tactical edge using laser connectivity is shown below (Figure 76). 
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The reality of this type of technology and concept is currently being 
studied. General Atomics Aeronautical Systems, Inc. were funded in 2002-2003 for an 
engineering task for the Jet Propulsions Laboratory Lasercom Terminal and UAV Laser 
Communications Project. In addition, according to Lree-Space Laser Communications 
Technologies, a demonstration was conducted from the UAV-to-Ground Lasercomm.68 

67 ADM fisher brief, (SEPT 2003) 

68 Berardo G. Ortiz, Shinhak Lee, Steve Monaeos, Maleolm Wright, and Abhijit Biswas, Jet 
Propulsion Laboratory, Californina Institute of Teehnology, Pasadena CA, “Design and development of a 
robust ATP subsystem for the Altair UAV-to-Gound Lasereomm 2.5 Gbps Demonstration” (SPIE, 2003) 
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This reinforces the idea of being able to use laser communications and UAVs together. 
Lawrence Livermore National Laboratory in Livermore, CA, is conducting additional 
work in an attempt to solve the ground to air tracking problem. 

b. Long Range, Ground-Based Laser Connectivity 
According to Jet Propulsion Laboratories, “a state of the art optical 
communications telescope laboratory to perform research and development of laser beam 
propagation and signal detection technologies to meet NASA’s future needs for high- 
bandwidth communications... ”69 is being examined. This illustrates the seriousness of 
the capability of laser communications. Another futuristic transformational 
communications concept is the ability to rely on the unique properties of femtosecond 
optical pulse in order to increase the current LOS capabilities. The authors recommend 
further studies into the femtosecond optical pulse capability. 

Attochron, LLC; a company based in Los Angeles, CA, specializes in free 
space optical communications technologies. According to Attochron, “Femtosecond 
optical pulses can provide a communications bandwidth 1,000 times greater than the 
current microwave line-of-site technology.”70 Tom Chaffee, Founder and CTO of 
Attochron, LCC; elaborates on Attochron’s capability, “Attochron’s free space optical 
(FSO) communications and power delivery technology utilizes the physics of the leader 
phase of lightning, air ionization, which allows Nature to transmit tremendous amounts of 
light and power through Earth’s normally insulative atmosphere. It’s interesting to note 
that this is possible often while in the presence of inclement weather (fog, clouds, and 
rain). Attochron uses two ultra fast lasers fired in sequence to achieve ionization of air. 
The first laser affects an ionized aerial waveguide unaffected by the diffraction of the 
atmosphere. A second laser, fired immediately afterwards, maintains the stability of the 
ionized pathway and provides, with its beam, the medium for either communications or 
power delivery.”71 The distance this technology can deliver is in the range of 28 km. 
Studies are currently being conducted to increase the distance and capabilities of this new 

69 K.E. Wilson, W.T. Roberts, V. Garkanian, F. Battle, R. Leblane, FI. Flemmati, and P. Robles, “Plan 
for Safe Laser Beam Propagation from the Optieal Communieations Teleseope Laboratory” (February 15, 
2003). 

70 http://www.attoehron.eom/ (May 2004) 

71 Tom Chaffee, “Femtoseeond Laser Air-Ioniztion for Free Spaee Optieal (FSO) Communieations 
and FSO Power Delivery” (Teehnieal White Paper, Attoehron, LLC 2002) 
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technology. This technology when proven sound could be an excellent fit for the 
UOC/CAC2S/CoNDOR sites for BLOS scenarios. 

c. OFDM in Aerial Relay 

A technology that is closer to being usable is OFDM in an Aerial relay. 
This concept is being studied at the Naval Postgraduate School (NPS) as follow-on 
research from this thesis. In a series of experiments called Surveillance Target 
Acquisition Network (STAN), NPS students are taking commercial-off-the-shelf OFDM 
products to extend the BLOS capabilities in a tactical environment. The method by 
which this is accomplished is by placing the OFDM technology in a tethered balloon or 
by placing the technology in an aerial relay. 

In the next STAN experiment, OFDM will be placed in an aerial relay in 
order to increase BLOS capabilities. OFDM’s unique wave characteristics yield 
capabilities for this technology to communicate BLOS. The scenario will consist of a 
100-mile distance being covered by an OFDM signal. However, there are concerns that 
OFDM may not be able to be amplified from the aerial relay. Regardless, one site will be 
located at NPS (Monterey, CA), while the other site will be in Camp Roberts, CA. The 
aerial relay will retransmit the OFDM signal between sites. The expected throughput 
values are in the neighborhood of 10 to 20 Mbps. The capability of passing sensor, 
voice, and computer data will be tested on the IP-based OFDM backbone. This 
demonstration is an example of how UOC/CAC2S/CoNDOR can take advantage of 
commercial-off-the-shelf technology and implement it in a tactical environment in order 
to communicate in a BLOS scenario. 

2. FORCEnet Application 

A wireless recommendation in a FORCEnet scenario consists of integrating a call 
for fire scenario on the tactical battlefield with wireless technologies. In a study 
conducted by Space and Naval Warfare Systems Command (SPAWAR), Charleston, SC; 
they addressed this recommended wireless solution for the FORCEnet scenario. 

Efforts spear-headed by Dennis E. Gette, code 61B Transformational Science and 
Technology; have demonstrated a prototype EORCEnet Engagement Package (ENEP) 
Combat Reach Capability (CRC). The ENEP is a small-scale system that integrates joint 

sensors, platforms, weapons, networks, and Command and Control (C2) systems. The 
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CRC is achieved through distributed services available in the FORCEnet cloud via the 
FNEP. An extraet of the demonstration is provided as a reeommendation for an 
integrated transformational network-centrie environment for a futuristic 
UOC/CAC2S/CoNDOR. 

SPAWAR-Charleston demonstrated a scaled-down prototype version of a 
FORCEnet-enabled CRC. The prototype is based on a Call for Fire (CEE) As-Is 
Operational View (OV). Aecording to Mr. Gette, “The As-Is OA for a USMC CEE is 
presented as an Operational View (OV-1) in Figure 77. The OV-1 serves to illustrate the 
sequenee of tasks or operational aetivities that take plaee as dictated by current Taetics, 
Teehniques, and Proeedures (TTPs).”72 Figure 77 depiets the current call for fire 
seenario. 


72 Dennis L. Gette, Space and Naval Warfare Systems, Transformational Science and Technology; 
“Demonstrate a Prototype FORCEnet Engagement Package (FNEP) Combat Reach Capability (CRC)” (Jan 
2004) 
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Figure 78. AS-IS CALL FOR FIRE OPERATIONAL VIEW (OV-I) 

The eurrent proeess requires Forward Observers (FOs) and Forward Air 
Controllers (FACs) to plaee the eall for fire. The FO eonverts the information to an 
AFATDS input and passes the input to the Company (Co) level. The CO deeides if the 
eall for fire is valid and then passes the information to the Bn. The Battalion Fire Support 
Coordinator (Bn FSC) passes the input to the Bn CO, who decides if the call for fire is 
valid. The Bn CO then tasks the Bn FSC to validate the request, selects the weapon 
system, and passes the request to the selected unit. 

A couple of points to take away from the OV-1 are: (1) The task of converting 
information to AFATDS input is sometimes difficult, suggesting that a sensor should 
automatically convert the input into useable data. (2) The OV-1 relies on single channel 
radios to communicate with Co HQ and Bn FSC Center. This connectivity maximizes at 
16 kbps, which is low throughput on the tactical battlefield. (3) The final point is the FOs 
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and FACs do not have access to a common operational picture. Current TTPs do not 
prescribe the need for a common operational picture at that level and many will argue 
within the operational community that the FOs and FACs do not have the time to look at 
or use the common operational picture. 

According to Mr. Gette, “Under the (unofficial) STOM CONOPS portrayed in 
Figure 78, platoons can call for fire directly. In this To-Be OV, a different Operational 
Facility (OPFAC) other than the Bn FSC can validate the CFF, select the appropriate 
weapons system(s), convert the request to AFATDS format, and pass the request to the 
selected unit. Notice that the Co only intervenes if the call for fire is inappropriate (e.g., 
based on a target’s value or priority).”73 The figure below provides an environment for 
the junior leaders to make decisions based on the Commander’s intent. This environment 
favors centralized command and decentralized control meaning the junior leader is 
capable of carrying out the Commander’s intent with minimal supervision. A network¬ 
centric environment should provide higher commands with the capability to pass 
information down to the lower echelons and promote more efficient, synchronized 
operations without impacting centralized command and decentralized control. 
Implementing this approach would require significant changes to existing Tactics, 
Techniques, and Procedures. 


73 Dennis L. Gette, Space and Naval Warfare Systems, Transformational Science and Technology; 
“Demonstrate a Prototype FORCEnet Engagement Package (FNEP) Combat Reach Capability (CRC)” (Jan 
2004) 
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Figure 79. TO-BE CALL LOR LIRE OPERATIONAL VIEW (OV-I) 

According to Mr. Gette, “The Last Ethernet Tactical Network is based on an on¬ 
going effort by SPAWAR-Charleston and the USMC to test and evaluate new approaches 
for improving the mobility and performance of tactical networks that will support the 
multi-function/multi-mission node-to-node operations of the CAC2S.”74 The Past 
Ethernet Tactical Network was used for the prototype experiment. The prototype 
experiment reinforced the efforts of the current authors because the prototype 
demonstrated Tree Space Optics (wireless technology) as potential solutions for intra- 
nodal and inter-nodal connectivity for UOC or CAC2S. 


74 Dennis L. Gette, Spaee and Naval Warfare Systems, Transformational Seienee and Teehnology; 
“Demonstrate a Prototype FORCEnet Engagement Paekage (FNEP) Combat Reaeh Capability (CRC)” (Jan 
2004) 
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According to Mr. Gette, “For the limited demonstration shown in Figure 79, an 
FSO link will be used to distribute a Common Taetieal Pieture (CTP) from a Command 
and Control (C2) Producing Node to an FO, Co, or Bn FSCC Consumer Node on the 
FORCEnet Taetieal Internet. By subseribing to an up-to-date CTP, it may be possible for 
partieipating units in an Amphibious Assault Operation to eoordinate and conduet a Joint 
Fire Operation on multiple fixed, moving, and aerial targets.”75 
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Figure 80. FAST ETHERNET TACTICAL NETWORK 

The East Ethernet Taetieal Network above demonstrated the potential capability 

of a call for fire seenario. The important faetor to extract is that the throughput on the 

75 Dennis L. Gette, Spaee and Naval Warfare Systems, Transformational Seienee and Teehnology; 
“Demonstrate a Prototype FORCEnet Engagement Paekage (FNEP) Combat Reaeh Capability (CRC)” (Jan 
2004) 
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tactical battlefield is eurrently limited and stove-piped. Through eontinuous efforts by 
the FORCEnet studies group and ageneies like SPAWAR-Charleston a network-eentrie 
environment will be available for the taetieal warrior. 

Dennis Gette sums it up best by saying, “The bottom line is that bottleneeks and 
ehokepoints between the Ground and Aviation Combat Elements of the MAGTE are 
eommon oeeurrenees beeause of high network loading and low throughput. To further 
exaeerbate this problem are the interoperability ehallenges that are ereated by the added 
eomplexity of the strueture and employment eonsiderations of other Serviee equipment, 
ageneies, doetrine, and personnel in joint operations.”76 

3. Follow-on Research 

The next several paragraphs diseuss possible follow-on researeh for other thesis 
students to address. These are areas the authors believe may assist the UOC, CAC2S, 
and CoNDOR programs even further as this thesis work is eompleted. 

Eirst, throughout the testing evolutions of this researeh the authors implemented 
eommereial off-the-shelf teehnologies into the established networks formulated by the 
authors. The data eolleeted was mostly throughput data of file transfers, voiee ealls, and 
streaming video. This did not replieate aetual data produeed by a UOC, CAC2S, or 
CoNDOR seenario. During May 2002, CAC2S used an Optimized Network Engineering 
Tool (OPNET) to model the aetual network traffie that would be generated during live 
operations. This model was using the MRC-142 and TRC-170 throughput eapabilities 
between nodes and fiber runs in the intra-nodal setup. Eurther researeh eould be done 
with OPNET to model and simulate the new wireless teehnologies reeommended for eaeh 
of the three programs. This would provide further examination of the benefits of these 
transformational wireless teehnologies for the Marine Corps. 

This researeh projeet dealt mostly with point-to-point oommunieations. 
Therefore, a single point of failure within the network arehiteeture would eause 
degradation aeross the entire network. Eor example, in Eield Test Eour if eonneetivity 
through the tethered balloon was lost, the NOC would not have been able to 

76 Dennis L. Gette, Space and Naval Warfare Systems, Transformational Science and Technology; 
“Demonstrate a Prototype FORCEnet Engagement Package (FNEP) Combat Reach Capability (CRC)” (Jan 
2004) 
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communicate with MRC #1 and MRC #2. If the NOC was employing some type of 
point-to-multipoint technology that connected to the POP and MRC #2, then redundant 
eommunieations would have been established. Follow on researeh could focus on the 
point-to-multipoint teehnologies that this researeh was unable to address. 

The above statements also yield to a good lead into another research area, whieh 
is mesh arehitecture. In mesh architecture, the communication devices in the network 
reeognize eaeh other. This leads to a self-healing, self-forming network when in each 
communication device can sense the other communication devices in its environment and 
is able to eommunicate within its surroundings. Once the eommunication deviee 
identifies its surroundings, then it can relay information via the mesh arehitecture to its 
neighboring devices. This type of teehnology is a truly network-eentric environment that 
is required for the future. 

Next, Broadband satellite was employed during Field Test Four. It provided 
stationary communications services, but the satellite dish mounted on the SUV was able 
to pull into a site and automatically track where the satellite antenna was loeated. If this 
type of service ean be provided while on-the-move, units ean keep an updated eommon 
operational picture even when displacing. Omega Systems, maker of the satellite dishes 
at Field Test Four, said they are working on these satellite eapabilities for on-the-move 
communications. Follow on research could study the impact of using high throughput 
(Broadband satellite) capability while in motion and how it can effectively be 
implemented into the UOC, CAC2S, and CoNDOR. 

Several technologies that provide transformational throughput were evaluated in 
this researeh. Most had no eneryption built into them, the exception being Redline and 
Alvarion with their OFDM produets. Further research is also warranted to identify if the 
teehnologies tested could have Type 1 encryption built into them. Sinee Type 1 
encryption is currently in stand-alone devices, the researched being suggested is to imbed 
the encryption into the product. Since Harris did this with their SecNet-11 cards, the idea 
should be feasible, providing the proper agencies were involved. If so, this would 
alleviate having to insert two bulk encryption devices into either side of a link to encrypt 
and decrypt information. 
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Furthermore, the next topic of conducting a cost analysis of replacing legacy 
communications systems with the commercial off-the-shelf technologies could also be 
researched. While the cost of the product can be taken into consideration, the cost of 
encryption may be the biggest expense. A formula could be developed to determine what 
is more important to the Marine Corps — cost or capability. 

The technology that proved most impressive during the last two field tests was 
OFDM. To incorporate a technology in the Marine Corps architecture that can 
communicate over hills, through trees, and around building may save lives by eliminating 
the need for retransmission sites. This research did not evaluate OFDM while traversing 
over large mountains. A breaking point of where the technology is still useful would be 
another good follow on research topic. In addition, the use of OFDM was not evaluated 
over water. Since the technology breaks up a single carrier into multiple carriers, more 
detailed research could identify if water has any adverse effects on the usefulness of this 
technology. Finally, OFDM is unproven in aerial relays. The need to research whether 
the signal can be amplified in an aerial scenario would be beneficial. This would identify 
if the technology were better suited to employ aerial than 802.1 lb. 

There is only one NSA certified Type 1 encryption device known that can encrypt 
classified traffic in a wireless LAN. This device is the Harris SecNet-11 card. Much 
research has been done with the product, but more extensive research needs to be done to 
identify how a SecNet-11 access point handles multiple users in a wireless LAN at the 
same time. This follow on research would identify how much traffic load an access point 
could handle, and how these access points need to be employed at different levels of 
command. 
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APPENDIX 


A, FSONA 

fSONA Communications is a provider of current and next generation FSO 
solutions. Their corporate headquarters is in Richmond, British Columbia, Canada. 
Founded in 1997 with a goal to develop optical transmission products for the broadband 
access market, IBONA created the SONAbeam™ family. The SONAbeam comes in 
three different series, M, S, and E. The M series has four transmitting lasers, the S 
series and E series have two. Each series offers different throughput capabilities that 
vary from 1.5 Mbps to 1.25 Gbps.77 lEONA has also recently completed the 
development of an OC-48 prototype system, the SONAbeam 1250-M. The SONAbeam 
155-M and SONAbeam 155-E were used during this thesis research. 

Throughout the testing evolutions, we noticed many advantages of the 
SONAbeam 155-M. The SONAbeam 155-M puts out 640 milliwatts of power, which 
is the most of any company’s product we worked with, and its four transmitting lasers 
help offset effects of scintillation. The SONAbeam 155-M advertises the longest 
distance at 5700 meters out of any ESO product, which was within the scope of our 
testing. The skin of the SONAbeam 155-M is made of cast aluminum, which is very 
durable material. Cast aluminum is designed to withstand rugged environments such as 
those encountered in the military. Einally, the lasers use the 1550 nanometer 
wavelength, which is suitable for the military due to laser designators being in the 700- 
850 nanometer range. 

A couple of disadvantages to the SONAbeam 155-M were that it requires a very 
stable platform to be mounted on. Both heavy duty (200 pounds) and lightweight 
mounts (50 pounds) were used during the testing events. The SONAbeam 155-M is 
also a very heavy piece of equipment weighing nearly 44 pounds. 


77 http://www.fsona.com (April 2004). 


217 




The SONAbeam 155-M is made for an environment that is static such as that 
found at an Air Command Node (ACN) within the CAC2S architecture. It could also 
be used at MAGTF level headquarters to connect the COC with the communications 
site. 

On the other hand, the SONAbeam 155-E is a very lightweight piece of 
equipment, which can be mounted on top of a telescopic stand. This allows the 
SONAbeam 155-E to be used with units that displace often. 

Eor information on lEONA and their products, contact Mike Corcoran at 877-463- 
7662 (office) or 604-312-6176 (cell). His e-mail address is mcorcoran@fsona.com . 


B. LIGHTPOINTE 

bounded in 1998 by Heinz Willebrand, Ph.D., a research visionary in the field of 
physics and lasers. EightPointe's application-specific Plight™ Optical Wireless family 
combines the speed of fiber with the flexibility of wireless. Their products transmit voice, 
data, and video at bandwidths ranging from single T-l/E-1 up to 2.5 Gbps at distances up 
to 4 km, over any protocol. Over 2,000 of their products are installed in over 60 
countries. Two of Eightpointe’s partners include Cisco and Corning Cable Systems.78 

The Plight product line includes the PlightEite, FlightSpectrum, and FlightStrata. 
During this research, the FlightStrata was used at connectivity speeds of 1.25 Gbps and 
155 Mbps. 

The unique aspect about the equipment used was the Fly Away kit that the link 
head and accessory equipment were packaged in. This consisted of a case that was about 
5x2x2 feet. A complete link would consist of having two cases, each weighing about 70 
pounds. The link was the easiest to establish out of all companies involved in this 
research project. From start to finish, a link was established within 15 minutes with two 
inexperienced personnel setting up the equipment. The stand was very lightweight that 
the link head was placed on. 


78 http://www.lightpoiiite.cotn/index.cftn/fuseaction/corporate.aboutus (April 2004). 
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Alignment of the lasers is fairly straightforward; the seope that is used to initially 
align the lasers is mounted within the link head and then LED bars light up on the back of 
the link head to signify the strength of the signal. Lightpointe chose to utilize the 750- 
850 nanometer range for their lasers, but they have stated that they could operate in the 
1550 nanometer range if the demand was established. 

Lightpointe’s Fly Away kit is ready for deployment right now, and it is definitely 
packaged the best out of all FSO companies. However, the skin of the link head would 
have to be ruggedized to withstand harsh environments. Their products could be used at 
any level in the UOC or CAC2S architectures. It also could be an option in the 
CONDOR setup at the company level talking to the POP vehicle. 

For information on Lightpointe and their products, contact Jim McGowan at 858- 
643-5216 (office) or 858-232-4873 (cell). His e-mail address is 
imcgowan@lightpointe.com . 

C. MRV 

Founded in 1988, MRV Communications, Inc. is a public company. With 1,500 
employees, MRV maintains eight R&D and manufacturing centers in the U.S., Europe, 
Israel, and the Far East and 50 customer service, support and sales offices in 22 countries. 
MRV FSO products sold to the Federal markets are U.S.A. manufactured. MRV is the 
Worldwide leader of FSO with more than 6,000 FSO links and have 19 FSO patents. 
MRV has over 20 years of R&D in FSO technology, and they were originally funded by 
DARPA to further develop the FSO technology. Their R&D included a 2,000 kilometer 
FSO link to a satellite supporting tracking. MRV has DoD installations of their FSO 
products including the Army and Air Force. Furthermore, MRV has four different 
product lines that they manufacture; Advanced Terminal Servers secure IT solutions for 
remote controFaccess, media converters, Terescope Optical Wireless (FSO), and Optical 
switches, routers, and modems.79 The Terescope 3000 was used during the testing 
evolutions, along with the FSO-RF automatic switch, OptiSwitch. 


79 http://www.mrv.cotn/corporate (April 2004) 
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Many advantages are found with MRV and their products. First, the company has 
been around for a long time and they have a diversity of products, so they do not rely 
solely on FSO for revenue. For these reasons, they are a company to depend on for the 
long term. The Terescope 3000 was set on a lightweight telescopic stand and it was 
relatively easy to setup. It had a camera alignment tool so one could see the laser light 
from the opposite end on the viewing screen. This allowed for the link head to be easily 
maneuvered into the cross-hairs on the screen for alignment. The OptiSwitch was quite 
impressive. When FSO and RF links are attached using the MRV patent Terescope 
Fusion, the Terescope Fusion automatically goes to the strongest link. Thus, if fog rolls 
in and the FSO link loses signal to the other side, then the RF takes over. This is all 
transparent to the user as there was no time delay or break in transferring files. For 
MRV’s media converters, the latest technology allows one to pick and choose what 
“pluggable” optical transceivers and/or electrical interfaces they want to use. These 
Small Form Factor Pluggables (SFPs) are also going to be engineered into future MRV 
FSO products which will allow the end user to always have the right interface to connect 
to the network equipment. The customer will not have to consider which scope head to 
purchase for single-mode or multi-mode fiber or worry about media converters. This will 
be built into the head of the scope. 

MRV’s Terescope products and accessories are suitable for any level of command 
in the UOC, CAC2S, and CONDOR communications architectures. 

For information on MRV Communications and their products, contact Tim 
Kcehowski at 724-934-5991 (office) or 412-596-1729 (cell). His e-mail address is 
tkcehowski@mrv.com . 


D, TERABEAM 

Terabeam was founded in 1997 and its headquarters is in Redmond, WA. They 
produce FSO products along with 60 GHz millimeter wave (MMW) systems.80 The 
Elliptica, FSO product, was used during our testing events, and the MMW system was 
demonstrated. 

80 http://www.terabeam.coiri/home.shtml (April 2004). 
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Terabeam uses only one laser compared to other companies that use multiple 
lasers. To paraphrase Carrie Cornish on February 4, 2004 at Raytheon in San Diego, CA, 
“...Terabeam uses a higher quality single laser, because over distance multiple lasers end 
up overlapping which provides no more of a benefit than the single laser...” The one 
laser does use the 1550 nanometer wavelength, a more favorable wavelength for use in 
military operations. 

The features that make Terabeam’s Elliptica stand out are the quality of their lab 
procedures in developing the product, significant auto-tracking feature that compensates 
for movement, ease of setup and teardown, minimal amount of small parts to lose over 
time, and the camera feature to align the links. 

After visiting Terabeam’s lab one could see the impressive procedures set in place 
to ensure the product is fully developed and tested before going to the customer. The 
auto-tracking feature is also unique. It can compensate for movement of buildings, 
accidental movement of the stand, and for the stand settling into the ground. Products 
that can be set up and torn down in an expedient manner are looked at favorably in the 
military environment. It is also important to develop systems with a minimal amount of 
small parts. Over time, small parts will definitely get lost in the military environment. 
The Elliptica was simple to set up, easy to use, and free of clutter and small parts. The 
camera feature for the alignment assists in establishing a link very quickly. After 
hooking up a laptop to the Elliptica, all the user has to do is look at the picture that the 
camera from the linkhead is providing and move the link head appropriately to line up 
with the other side. 

As the Elliptica is a very suitable alternative to the UOC, CAC2S, and CONDOR 
communications architectures, the skin of the Elliptica would have to be hardened for the 
constant wear and tear it would undergo in the field. 

For information on Terabeam and their products, contact Jim Olson at 610-408- 
9380 (office) or 206-604-7429 (cell). His e-mail address is iim.olson@terabeam.com . 
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E. ENSEMBLE 

Ensemble was founded in 1997 and its headquarters is in San Diego, CA. Their 
wireless broadband system (Fiberless) ineludes radio transmission base stations and 
antennas, multiplexers, and network management software capable of providing both 
Internet connections and voice services. Ensemble Communications designs, 
manufactures, and markets point-to-multipoint wireless system for Eocal Multipoint 
Distribution Services (LMDS).8i They also offer network design, product integration, 
and project management services.82 The 16200 Hub Station, the 320 Multiplexer, and 
the Fiberless 282 Series Outdoor Mounted Unit (ODU) were used for the experiments. 

Alignment of the antennas was straightforward; the authors pointed the antennas 
in the direction of each other. Once there was connectivity between the two antennas, the 
320 Multiplexer and the 16200 Hub Station would illuminate a connectivity light on each 
component respectively. The unique quality of their wireless broadband system was the 
three major components took little effort to set up. From start to finish, antenna 
alignment was established within 15 minutes with two inexperienced personnel setting up 
the equipment. In addition to the ease of antenna set up. Ensemble Communications took 
advantage of the available bandwidth by carrying the largest packet payload of any point- 
to-multipoint system.83 The largest packet payload is accomplished by Ensemble 
Communications’ Adaptix technology. Ensemble Communications’ Adaptix technology 
consisted of combining Adaptive Time Division Duplexing, Adaptive Time Division 
Multiple Access, and Adaptive Modulation. This patent maximizes the spectrum by 
taking advantage of the entire waveform. 

One disadvantage that Ensemble Communications faced during testing events was 
that equipment was an ATM based system. The configuration for the routers was 
extremely difficult and extremely time consuming. In one particular case, the router and 
network configuration took up to eight hours before any testing was able to take place. 

Ensemble Communications was closed in April 2004. 

81 http://www.ensemble.com (May 2004) 

82 http://www.hoovers.com/ensemble-communications/—ID 104236—/free-co-factsheet.xhtml (May 
2004) 

83 http://www.ensemble.com (May 2004) 
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F. ALVARION 

Founded in 1992, Alvarion was solely foeused on broadband. Alvarion is a world 
provider for Point-to-Multipoint (PMP) Broadband Wireless Access (BWA). Alvarion 
supplies integrated solutions to telecom carriers in order to assist telecom carriers in 
providing sustainable voice and data connectivity in the broadband market. The 
broadband market covers residential area, SOHO (small office, home office), markets 
through small and medium enterprises, and multi-tenant units/ multi-dwelling units. 
Alvarion introduced its BreezeACCESS VL system. The BreezeACCESS VE system is 
a PMP wireless broadband system which operates between the 5.725 to 5.850 Ghz 
frequency band. This system uses OFDM technology in order to maximize performance 
when the distant end is not line of sight. Some equipment characteristics include: an 
OFDM system. Adaptive modulation (BPSK, QPSK, 16 QAM, 64 QAM), a channel 
bandwidth of 20 Mhz, enhanced security, automatic transmit power control, and offers 
over-the-air software upgrade and configuration upload/download.84 

The BreezeACCESS VE demonstrated a quick and easy set up. The outdoor unit, 
which consists of antennas and a radio, was erected on a lightweight retractable pole, 
which was secured by parking a vehicle over the base plate of the pole. Once the outdoor 
unit was secured and aligned, the indoor unit was connected to the network’s router. 

The issue that Alvarion encountered was the alignment of the antennas. On the 
underside of the antenna, there is a module that indicates signal strength level, which is 
not visible when adjusting the antenna. This small dilemma could be resolved through 
the use of either moving the module to where it can be seen when adjusting the antenna 
or by replacing the module with some sort of audio indicator that notifies the technician 
the antenna is aligning properly. 

Eor information on Alvarion and their products, contact Jasper Bruinzeel at 760- 
517-3149 (office) or 760-685-2015 (cell). His email address is 
iasper.bruinzeel@alvarion.com . 


84 http://www.alvarioii-usa.com/RunTime/Materials/PDFFiles/alv BA%2QVL pg.pdf (May 2004) 
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G. REDLINE 

Founded in 1999, Redline Communications Inc. is headquartered in Markham, 
Ontario, Canada. Redline Communications is an innovative provider of second- 
generation broadband fixed wireless systems.85 Redline’s products are based on an 
advanced form of OFDM technology. This technology interlocks three different 
techniques which include the OFDM data engine; an increased efficiency of the medium 
access control layer and the radio frequency; and multipath distortion effects and 
interference. 

Redline Communications introduced the AN-50 OFDM system with sector and 
omni-directional antennas. The AN-50 system operates in the license-exempt 5.8 GHz 
band and includes advanced technologies to address potential inter-cell interference 
issues. The AN-50 maximizes spectral efficiency with a unique patented bi-directional 
adaptive modulation technique, automatically selecting any of eight modulation schemes 
providing a solid connection even in challenging link conditions. In addition, the AN-50 
delivers an over-the-air rate of up to 72 Mbps, a robust non-line-of-sight (NLOS) 
capability, and audible antenna alignment and diagnostic capabilities. 86 

Redline Communications equipment was very easy to set up. The alignment of 
the antenna was augmented by an audio signal that assisted the technician in the 
alignment. This feature proved to be extremely helpful in the set up / tear down process 
of the system. The OFDM technology demonstrated to be a BLOS technology up to 20 
km (depending on the antenna used). 

The only issue that Redline encountered during the testing evolution was that their 
switch could only be set to auto negotiate. In order to maximize throughput across the 
link, the test bed was designed around the network routers to be configured at speed 100 
Mbps with full duplex. The miss-matched configuration degraded the link across the 
network and limited the maximum throughput the equipment was capable of producing. 


85 http://www.redlinecommutiications.com (May 2004) 

86 Redline Communications, “Redline Family White Paper”, October 2003. 
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For more information on Redline Communications and their product, contact 
Dave Rumore at (905) 479-8344 (office) or (561) 254-0758 (cell). His email is 
drumore@redlinecommunications.com . 

H, SEGOVIA (BROADBAND SATELLITE) 

Segovia was founded in 2002 and is headquartered in Herndon, Virginia. Segovia 
provides omnipresent Global IP networks and services. The IP coverage that is provided 
by Segovia covers virtually a unified global network. During the testing evolution, 
Segovia was teamed up with Omega Systems, a company who produces the satellite 
dishes. Segovia’s throughput can range from 128 kbps to 9 Mbps. Segovia’s Internet 
service features no limit on monthly usage, high performance with low cost, Type-1 
encryption compliant, and a fully managed solution. Segovia’s IP Voice features high 
quality voice, full range of PBX features, and reduced costs. In addition, Segovia offers a 
VPN feature, which includes easy IP administration, security, use of the Internet, and 
completely private network. 87 

Segovia’s customer service and teamwork left a customer oriented impression on 
these authors. Senior Sales Engineer, Ross Warren, went above and beyond expectations 
in order to assist in making Field Test Four a success. His coordination with his 
headquarters arranging for the airborne satellite to act as a retransmission site for the li nk 
between the two testing sites was key. In addition to providing customer support for his 
equipment, he also assisted the students with the configuration of the entire network of 
routers, switches, access points, and IP phones. 

For more information on Segovia or Segovia’s services, contact Jeff Howard at 
(703)621-6450. His email is ieff.howard@segoviaIP.com . 

I. OMEGA SYSTEMS, INC. 

Omega Systems, Inc. was founded in 1998 and is headquartered in Colorado 
Springs, Colorado. Omega Systems was the company that provided the satellite antennas 
for Field Test Four. Omega Systems is not only a satellite antenna company. They also 

87 http://www.segoviaip.com/ (May 2004) 
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develop requirements-based solutions derived from a thorough analysis of the customer’s 
internal process and external communications needs.88 Omega Systems provides the 
following products and services: Business Process Analysis and Re-engineering, 
Requirements Analysis, Network Engineering, Application Engineering, System Analysis 
and Integration, C4ISR Architecture Analysis, Internet Business Solutions, and IT 
Equipment Sales and Services.89 

Marine Corps specific projects that Omega Systems Inc. has supported with onsite 
support are: C2 Operational Architecture for Marine Corps Combat Development 
Command (MCCDC); Network Design, Installation, and Management for Marine Corps 
Institute; Warfighting Eunctional Analysis for MCCDC; USMC Online Correspondence 
Course System for Marine Corps Institute; LHA-R Operational Architecture for MCCDC 
and SPAWAR, and Single Integrated Operational Picture for MCCDC.90 

Omega Systems, Inc introduced two one-meter satellite terminals during the field 
testing evolution. One terminal was a ground terminal that was utilized at the Mobile 
Research Eacility; the other was mounted on a Sports Utility Vehicle and was located at 
the remote site. The ground terminal was a multiple case system that was powered by a 
llOV source, and its transmitting frequency was between 13.75 - 14.50 GHz with a 
receiving frequency between 11.70 - 12.75 GHz. The satellite dish was manually 
pointed at the satellite for connectivity. The mounted terminal required the same power 
load and it operated in the same frequency band. However, it automatically aligned itself 
to the satellite once it was turned on. This yields for a quick setup time and operation of 
the equipment can begin within minutes. 

Eor more information on Omega Systems, Inc. contact Matt Jones at (719) 886- 
2212 (office) or (719) 337-1588 (cell). His email address is miones@omegasvs.net . 


88 http://www.omegasvs.net/documents/corporatecs.pdf (May 2004) 

89 www.omegasvs.net (May 2004) 

90 Matt Jones, VP Business Development, “Past Performance Addendum, Omega Systems Inc.” (May 
2004) 
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J. NERA (INMARSAT) 

Nera ASA, based in Norway, was established in 1947, and it is one of the world's 
leading eompanies in the field of wireless teleeommunieations using mierowave and 
satellite teehnology. The company has offices in 26 countries and more than 1,500 
employees around the world. Separate companies for product development and sales are 
located in Boston, MA and Dallas, TX.91 Nera’s NWC Voyager system, INMARSAT 
capabilities on-the-move, was looked at closely during the March testing event. Marine 
Corps Systems Command is also looking at Nera for possible mobile communications for 
the CONDOR architecture. Finally, the World Communicator was also demonstrated but 
not used during the course of research in these testing evolutions. 

NWC Voyager is a vehicular Global Area Network (GAN) satellite terminal 
operating over INMARSAT 1-3 in spot-beam, prepared for 1-4. The GAN capability 
combines the high quality and speed of the full mobile ISDN 64 kbps service with the 
flexibility of Mobile Packet Data Services (MPDS).92 

As discrete and convenient as hand luggage, the Nera WorldCommunicator 
enables one to access the internet and send and receive e-mail, data files, fax and voice 
messages from one compact unit anywhere in the world. By linking two units together 
the throughput is doubled to 128 kbps.93 

During the testing, the NWC Voyager was easily mounted on a solid platform 
made of wood in the back of a pickup truck. While the vehicle was in motion, phone 
calls and fide downloads were performed without error. There were some issues, 
however, when the look angle of the Voyager was blocked by hills next to the vehicle the 
download was unsuccessful. In addition, integrating the Voyager system into the 
established network was not accomplished during the testing event. 

Nera’s products are definite players in the military, mobile communications 
realm. Communicating on the move has emerged as a requirement to keep commanders 
informed at ah times. 

91 http://www.nera.no/index.html (April 2004). 

92 http://www.nera.no/5243067FA7B57D0BC1256E510054623A.html (April 2004). 

93 http://www.nera.no/844AED60C2F14035C1256A300054A93D.html (April 2004). 
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For information on Nera and their products, contact Peter Coffman at 713-294- 
4543 (cell). His e-mail address is pc@nera-sp.com . 

K. IMUX (IRIDIUM) 

General Dynamics’ Reachback Iridium Inverse Multiplexer (IMUX) combined 
four 2.4 Kbps Iridium channels to increase the overall bandwidth to 9.6 Kbps.94 The 
IMUX utilized the channels by separating the input information and sending the parsed 
information across the four different channels. Another Reachback unit recombines the 
original information by using buffers in order to compensate for variations in link delays 
produced from the four satellite channels.95 The four L-band channels were wired into 
the IMUX box that provided three modes of operation; data, video, and voice 
transmission. The data mode ensured data was not altered during transmission (data files, 
critical imagery, etc.). The video transmission mode did real-time video transmission 
using custom video compression software (used when loss of video quality can be 
tolerated). The voice mode was a satellite telephone. 

The Reachback can be implemented in a variety of combinations to include 
mobile-to-mobile, mobile-to-network, and mobile-to-Public Switched Telephone 
Network (PSTN). The mobile-to-mobile configuration allows two Reachback units to 
communicate with each other. The mobile-to-network allows a mobile Reachback unit to 
communicate back to a central server. The mobile-to-PSTN configuration allows a 
mobile Reachback unit to communicate to four standard PSTN phone lines. 

During the testing, the product performed as expected. The IMUX is definitely a 
current solution option for BLOS. Although the throughput is limited, the product does 
offer configurations that augment more data throughput on the tactical battlefield. 

For more information on the IMUX, contact Don Lesmeister at (480) 441-0340 
(office) or (480) 518-2208 (cell). His email address is Donald.Lesmeister@gdds.com . 


94 http://www.gdds.com/satelliteservices/ (May 2004) 

95 www.gdds.com . white paper, “Reachbak Iridium Inverse Mulitplexer for Over-the-Horizon 
Worldwide Transmission of Voice, Video, and Data” (May 2004) 
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L. GENERAL DYNAMICS (REM) 

The Radio Frequency Module is a product produced by Ceragon Networks; 
however, the product is packaged by General Dynamics Decision Systems (GDDS). 
GDDS packages the product in appropriate cases along with a Cisco 2950 switch for their 
customers. This case along with the microwave dish is field expedient and hardened to 
withstand a rugged military environment. The antenna sits on top of a lightweight 
telescopic stand, which is separate from the case. A distance of 9 kilometers can be 
reached with the one-foot antenna, which was used during the testing event, and 13.5 
kilometers with the two-foot antenna.96 RFM is a point-to-point, line-of-sight, OC-3 
capable (155 Mbps) microwave product. 

According to a General Dynamics data sheet, “RFM v3 contains a baseband 
assembly with power supply, an Ethernet switch, and a dual DSl to fiber optic modem 
that is operated and maintained inside the transit case located inside user provided 
facilities. It also contains an RF assembly and antenna that are installed and operated 
outside the user provided facilities up to 200 feet away.”97 This self-contained system 
demonstrated a consolidated system that provided high 80’s Mbps throughput of data. 

During the testing, the product was very impressive. The RFM could be 
implemented now in the Marine Corps for intra-nodal and inter-nodal connectivity. 

For more information on the RFM, contact Jon Seime at (480) 441-2983 (office) 
or (480) 510-4126 (cell). His email address is ion.seime@gdds.com . 


M. KG-235INE 

GDDS is the manufacturer of the KG-235 Sectera In-Line Network Encryptor 
(INE). The KG-235 is specifically designed to support IP/Ethemet operating over 
standard commercial networks that require U.S. Government Type 1 security, but it is 
also used in the military environment. The INE protects all levels of data, from 
Government Classified to TS/SCI. It provides confidentiality, data integrity, peer 
identification, authentication and mandatory/discretionary access control services. The 

96 GDDS, “Radio Frequency Module (RFM) v3 Handout”, 2003. 

97 GDDS, “Radio Frequency Module (RFM) v3 Data Sheet”, 2003 
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INE is software configurable, it utilizes the new Sectera INE Configuration Manager, and 
it is keyed using material supplied by the U.S. Government’s Electronic Key 
Management System (EKMS) for Type 1 products.98 The interfaces on the INE are two 
RJ-45 10/100 Base-T and two DB-9 Serial Ports. The INE can support up to 17 Mbps of 
aggregate data throughput.99 With further upgrades, the INE will be able to support up to 
60 Mbps. 100 

During the testing, the product did not perform as expected. The INE needed the 
latest firmware in order to maximize a greater throughput and the authors were expecting 
a higher throughput result from the product. When the INE was tested at Raytheon, the 
INE had an older version of firmware installed. The INE specifications rate the product 
up to 17 Mbps aggregate data throughput, loi The maximum throughput observed for the 
INE was around 5 Mbps. 

Eor more information on the INE, contact Don Eesmeister at (480) 441-0340 
(office) or (480) 518-2208 (cell). His email address is Donald.Lesmeister@gdds.com . 


N. SECNET-11 

SecNet-11 is a Harris product. Harris Corporation is an international 
communications equipment company focused on providing product, system, and service 
solutions for commercial and government customers. 102 The company is headquartered 
in Palm Bay, Elorida. Providing service worldwide, Harris has sales and service facilities 
in more than 90 countries. 103 

SecNet-11 is a tool for a secure 802.1 lb wireless local area network. The SecNet- 
11 product family offers a scalable, mobile, quick to deploy solution for a military 
environment. The SecNet-11 family includes products like the SecNet-11 Plus PC card, 

98 http://www.gdc4s.coiii/Products/sectera.htm (April 2004). 

99 http://www.gd-decisioiisvstems.com/sectera/ine/upgrade/C4SSectera INE PIB V2 12-5-03.pdf 

(May 2004) 

100 Donald Lesmeister, GDDS sales engineer, phone eonversation (February 2004) 

101 http ://www. gde4s. eom/Produets/seeteraspees .htm 

102 http://www.harris.eom/ (May 2004) 

103 www.harris.eom (May 2004) 
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the SecNet-11 PC card, the SecNet-11 Wireless Bridge, the SecNet-11 Access Point, and 
the SecNet-11 Key Fill Cable. Based on the IEEE 802.1 lb standards, the SecNet-11 Plus 
PC card has been certified as part of the National Security Agency’s (NSA) Commercial 
COMSEC Evaluation Program (CCEP).i04 

As discussed in the thesis, SecNet-11 operated as expected. SecNet-11 is a secure 
National Security Agency (NSA) Type 1 and FIPS-140 compliant encryption device. 
Therefore, classified information up to Secret can be passed across a SecNet-11 network. 

For more information on SecNet-11 and its family of products, contact Mark 
Slepikas at (321) 727-5141 (office) or (321) 917-7019 (cell). His email address is 
mslepika@harris.com. 

O. JTRS 

According to Harris, “The Joint Tactical Radio System (JTRS) is a U.S. military 
initiative to develop a family of software programmable and modular communications 
systems that will become the principal means of communications for warfighters in the 
digital battlefield environment. All waveforms, protocols, encryption, and 
communications processes will be implemented in Software Defined Radio (SDR) 
technology. JTRS is a family of affordable, high capacity, software programmable 
tactical radios providing interoperability for line of sight, and beyond line of sight in a 
wireless mobile network. JTRS is identified in five clusters; cluster 1 will consist of 
ground vehicular, rotary wing, and TACP; cluster 2 will consist of handheld devices; 
cluster 3 will consist of Maritime and fixed sites; cluster 4 will consist of fixed-wing 
(Airborne); and cluster 5 will consist of embedded devices.”105 According to LtCol 
Wilson, “...through the addition of WNW, the JTRS will significantly improve tactical 
networking on the battlefield.”!06 

Testing was not conducted due to the infancy of the system. Therefore, JTRS is 
briefly discussed in the conclusions of this thesis. For further information on JTRS and 

104 http://govcomm.harris/secure-comm/ (May 2004) 

105 http://www.rfconmi.harris.com/itrs.html (May 2004). 

106 Jefferey D. Wilson, Lieutenant Colonel, United States Marine Corps, “Introducing the Joint 
Tactical Radio” (Marine Corps Gazette, Aug 2002) 
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its clusters, contact Captain Andrew G. Chapman, United States Marine Corps, at (703) 
432-4360. His e-mail address is ChapmanAG@mcsc.usmc.mil . 


P. ATM 

As mentioned earlier. Ensemble operated off an Asynchronous Transfer Mode 
(ATM) network. The ATM was developed because there was a need for delivering 
services (video, voice, and data) at high rates of speed across a network of computers. 
Networks of the past consisted of a network of telephone systems. Integrated Services 
Digital Network (ISDN). The technology ATM replaced was circuit switched Time 
Division Multiplexing (TDM). The nice feature ATM offered was that ATM provided 
more bandwidth to be available across the network when compared to TDM. Most 
carriers of Internet Protocol (IP) services have maintained for years an ATM layer over 
which IP traffic travels. This was due to the reliable, scalable, higher availability, and 
Virtual Private Network features that lie within ATM and lack in traditional IP, such as 
the lack of flow control and sequencing. IP technology today does not lack flow control 
or sequencing. 

The manner in which ATM worked with data has changed drastically over the 
past decade. ATM in the past had a major shortfall in data environments due to “cell- 
tax”, meaning there was significant overhead in packet-oriented networks. For instance, 
if a piece of data was sub-divided into ATM’s short fixed length packets of 53 bytes and 
several packets were full except one which only had a few bytes in it, then ATM’s 
overhead would fill that packet and send it across the network. This was not the most 
practical of solutions, so adoption of the Frame-based ATM over Synchronous Optical 
Network (SONET)/Synchronous Digital Transport took place. ATM still continued to 
add value to IP-based services through means like SONET. ATM would also 
simultaneously offer other non-IP applications and services to reside on the same core 
infrastructure. However, according to Comer, “ATM has not been widely accepted. 
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Although some phone companies still use it in their backbone networks, the expense, 
complexity and lack of interoperability with other technologies have prevented ATM 
from becoming more prevalent.” 107 

Q. LINKSYS (802.11A/802.11B) 

Linksys is a company that merged with Cisco. The authors used several access 
points made by Linksys. In particular the WAP55AG was used in access point 
configuration. The WAP55AG is a Linksys Dual-Band Wireless A+G Access Point. 
The product contains two separate radio transceivers in order to support three wireless 
specifications. The first transceiver, 2.4 GHz frequency band, supports the 802.11b 
standard and the 802.llg standard. The second transceiver, 5.4 GHz frequency band, 
supports the 802.1 la standard. 

The product was fairly difficult to configure in the beginning. Towards the end of 
the experiments the configuration of the product was straightforward because of the 
experience. This product would be a good fit within an unclassified military network. 

The WAP 11 was another Linksys product that was tested by these authors. The 
WAP 11 uses 802.11b standard for its technology. The WAP 11 was used in a bridge 
mode configuration to tie two networks together. The WAPl 1 was also used in an aerial 
relay configuration. Initially, the WAP 11 was fairly difficult to configure. The WAP 11 
was straightforward to configure at the end of all of the testing evolutions. Similar to the 
WAP55AG, this product can be used in an unclassified environment in the military. 

For more information on the Linksys or the Linksys products, contact George 
Delisle at 703-484-5733 (office) or 703-217-7599 (cell). His e-mail address is 
gdelisle@cisco.com . 

R. CISCO 

Cisco was founded in 1984 by a small group of computer scientists from Stanford 
University. It now has over 34,000 employees and is based in San Jose, CA. Cisco was 

107 Douglas Comer, “Computer Networks and Internets with Internet Applieations”, (Prentiee-Hall 
Ine, New Jersey 2001, third edition), pg. 229 
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founded on a culture based on the principles of open communication, empowerment, 
trust, integrity, and giving back to the communityios, and the authors witnessed these 
same values in their dealings with Cisco. In December 2003, the authors approached a 
Cisco Account Manager in the District of Columbia area, George Delisle, who works 
closely with the Marine Corps. A request was granted by Mr. Delisle to supply the 
authors with two Cisco 3745 Multiservice Access Routers, two Cisco IP Phone 7960Gs, 
one CallManager Server, two Cisco 350 Aironet Bridges, one ATM interface card, and 
four Gigabit Interface Converters (GBIC) to be utilized during their testing exercises. 

Key features for the Cisco 3745 are as follows: two integrated 10/100 LAN ports, 
two integrated Advanced Integration Modules (AIM) slots, three integrated WAN 
Interface Card (WIC) slots, four Network Module (NM) slots, two High Density Service 
Module (HDSM) slots, 32MB Compact Flash, 128MB DRAM, and support for all major 
WAN protocols and media. 109 

The Cisco IP Phone 7960G offers four dynamic soft keys that guide a user 
through call features and functions. Built-in headset port and integrated Ethernet Switch 
are standard with the Cisco IP Phone 7960G. It also includes audio controls for full 
duplex speakerphone, handset and headset. The Cisco IP Phone 7960G also features a 
large, pixel-based LCD display, no 

The Cisco Call Manager Server that was used was the MCS-7825H-2.2 
EVVl model. Next, the Cisco 350 Aironet Bridges were not used during the testing 
events. An ATM interface card provided a single-mode intermediate-reach (SMI) fiber 
uplink port with enhanced performance. This was used with Ensemble’s equipment. 
Einally, the GBIC accepted a multimode fiber at a wavelength of 850 nanometers, and the 
port took a SC-type connector. The GBIC was successfully used with Lightpointe’s fiber 
cable from their link head. 


108 http://newsroom.cisco.coiii/dlls/companv overview.html (April 2004). 

109 http://www.cisco.cotn/en/US/products/hw/routers/ps282/ps284/index.html (April 2004). 

110 

http://www.cisco.cotn/en/US/products/hw/phones/ps379/products data sheet09186a0080091984.html 

(April 2004) 
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For information on Cisco’s support, contact George Delisle at 703-484-5733 
(office) or 703-217-7599 (eell). His e-mail address is gdelisle@eiseo.com . 

S. SPIRENT (SMARTBITS) 

For decades, the world’s leading communications companies have used Spirent 
solutions to conduet performance analysis tests in labs on the latest technologies. As new 
communications services are introduced in the market, Spirent provides the tools to offer 
serviee assuranee and field test for improving troubleshooting and quality. Spirent 
Communications has 1,800 employees in 14 countries, and its headquarters is in 
Rockville, MD.m 

During the Raytheon testing, Spirent allowed the authors to utilize their Smartbits 
product to analyze the network and technologies being evaluated. The following is a list 
of the Smartbits products that were utilized during testing: SMB-600 Chassis, LAN 
3101B 6-port 10/100 Ethernet interface, SWF-1208A SmartVoIPQoS, and ACC-1040A 
Nanosync GPS Interface Kit. A separate company, Zyfer, provided the GPS receivers 
and antennas. 

The GPS receivers and antennas were used to synchronize the two chassis on 
separate ends. Unfortunately, the network at Raytheon headquarters was positioned too 
close to the building, so the look angle of the GPS antenna could not see the satellite. 
Thus, the two chassis could not provide any latency data, but they were able to provide 
throughput tests. 

Through the Smartbits packet generator, each technology was stressed to its 
fullest allowing one to see the exact throughput of the link. This was mostly done with 
voice and data traffic in a full duplex setup. At times, voice and data were done 
separately. For the most part, eight voice calls were replicated both ways, and data was 
sent in increments of 10 Mb starting at 10 and ending at 100 Mb. Overall, this setup 
allowed one to see what amount of frame loss was being experienced as traffic got 
heavier and heavier. As the frame loss become eloser to 100 percent, a determination 
could be made on the exaet throughput for the established link. 

111 http://www.spirentcom.com/about/index.cfm?wt=l (April 2004). 
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For information on Spirent Communications and their products, contact Jeff 
Blanchard at 408-752-7159 (office) or 408-464-8948 (cell). His e-mail address is 
ieff.blanchard@spirentcom.com . 

T. ZYFER (GPS) 

Originally named Odetics Telecom, Zyfer was established in the mid-'80s, and 
incorporated as Zyfer Inc. in 1999. FEI-Zyfer's parent company. Frequency Electronics 
Inc. (FEI), was founded in 1961 and quickly gained world prominence in the Precision 
Quartz Crystal Oscillator Technology. EEI-Zyfer designs and manufactures GPS-aided 
precision time and frequency generation and synchronization products for commercial 
and government users. It is based out of Anaheim, CA. 1 12 

During this thesis research at Raytheon, the Nanosync II was used to provide 
synchronization to both of Spirent’s chassis. This would allow for the VoIP QoS 
software to show accurate latency data. Unfortunately, one of the GPS receivers was 
positioned too close to a building, so it could not pick up enough satellites to provide 
proper signal. This location could not be moved. Thus, both chassis could not sync up 
and the latency data ended up being skewed. The Nanosync II was very lightweight and 
easy to use. It does take a special cable between the receiver and the antenna cable to be 
utilized. 

Eor information on EEI-Zyfer and their products, contact Eee Chenoweth at 949- 
713-9801 (office) or 949-433-2800 (cell). His e-mail address is 
lee@timingtechnologies.com . 

U. SOLARWINDS 

SolarWinds.Net, Inc. was founded in 1995 and is headquartered in Tulsa, 
Oklahoma. SolarWinds develops and markets an array of network management, network 
monitoring, and network discovery tools. SolarWinds is organized in three divisions; 
Network Toolset Division, the Orion Division, and the Broadband Division. The division 
that enhances and releases new network tools is the Network Toolset Division. The 

112 http://www.zvfer.cotn/aboutus.html (April 2004). 
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division that works on server based solutions providing a eomplete web view of the 
network is the Orion Division. Finally, the division that develops solutions for high¬ 
speed data networks is the Broadband Division.ns Aeeording to SolarWinds, their 
mission is “to provide Network Engineers and Consultants with a single eomprehensive 
tool-set to reaetively and proactively analyze, monitor and isolate networking issues.”114 

As mentioned in the thesis, SolarWinds was used to monitor the throughput in the 
network. Through the use of Simple Network Management Protocol (SNMP) with IP 
Network Browser and Internet Control Message Protocol (ICMP) the students were able 
to monitor the bandwidth utilization of a remote component on the network, the load on a 
Cisco router, or identify what devices were on a subnet. Additional detailed information 
it returned included details of each interface, port speed, IP Addresses, routers, ARP 
tables, and much more. 

During the testing periods, the students ensured the devices on the network were 
SNMP enabled prior to conducting any tests. SolarWinds measured CPU load and the 
Cisco routers load. The gauge used SNMP to communicate with the device and 
displayed the results on the computer screen (Figure 80). 
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Figure 81. SOFARWINDS CPU GAUGE 


The maximum throughput number was recorded onto a spreadsheet as the 
maximum throughput between two sites. 

113 http://www.solarwinds.net (May 2004) 

114 http://www.solarwinds.net/companv (May 2004) 
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For more information, contact Sales Department (918) 307-8100 or 

www.solarwinds.net. 


V. IPERF 

Iperf was a tool used to measure Transfer Control Protocol (TCP, a protocol 
developed for the Internet to get data from one network device to another) bandwidth, 
allowing the tuning of various parameters and User Datagram Protocol (UDP) 
characteristics. Iperf reports bandwidth, delay jitter, and datagram loss. The program 
can be downloaded for free from the Internet. The authors used Iperf version 1.1.1, 
which was released in February 2000 for all the testing found in this thesis. There were a 
couple of ways to execute the program. One way was to run the batch file on the sending 
side while simultaneously running the batch file on the receiver’s side. The second 
option was to go into the DOS prompt and type in the following commands once the user 
was in the Iperf folder, the sender would type “IPERF -c” (IP address packets are going 
to) “-W 8K 5 20” and the receiver would type “IPERF -s -w 64K”. The meanings of the 
letters above are as follows; -c means to run Iperf in client mode; -w determines the TCP 
window size (sets the socket buffer sizes to the specified value, in the example above the 
window size is 8K. For TCP, this sets the TCP window size.); 5 is the transmit time of 
bytes; 20 is the time interval of transmission; -s means to run Iperf in client mode, 
connecting to an Iperf address that is running the host; -w is the window size for the 
receiving side, in this case, the size of the window is 64K. 

Currently, there is an Iperf version 1.7.0 that can be downloaded from the 
Internet. If interested in more information on Iperf, go to http://dast.nlanr.net/. 


W. VOIP 

Voice over Intenet Protocol (VoIP) defines a way to carry voice calls over an IP 
network including the digitization and packetization of the voice streams. IP Telephony 
utilizes the VoIP standards to create a telephony system where higher-level features such 
as advanced call routing, voice mail, contact centers, etc., can be utilized. ii5 

115 http://www.cisco.cotn/en/US/tech/tk652/tk701/tech protocol family home.html (April 2004). 
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Cisco 7960G IP telephones were used to provide voice service to the Loeal Area 
Networks (LAN). The phones took a simple CAT-5 cable connection, and the other end 
was connected to the LAN switch. The Call Manager server was always loeated with the 
Mobile Research Facility (MRF). The phones throughout the Wide Area Network would 
first talk to the server before making a call to another phone within the network. The 
server was conneeted to the MRF switch via CAT-5 cable. Each phone and server was 
assigned its own unique IP address. 

From the testing, whenever SolarWinds measured a signifieant packet loss of 
greater than 10% in the li nks established between LANs, VoIP calls would drop. The 
exception to this was using OFDM. Since this technology splits its bandwidth into 
multiple channels, as long as one channel is getting across it will keep the call up. For 
example, when SolarWinds showed the link was down, greater than 50% packet loss, the 
VoIP eall was still active. Finally, the network routers were all set to have voice as the 
number one priority. 

For further information on the VoIP testing data, reference LT Manny Cordero’s 
thesis researeh. This can be found through the NPS library at 
http://librarv.nps.navv.mil/home . 

X, MLB (UAV) 

Since 1988, MLB has defined the state of the art in small aerial platforms that 
include the tiny Trochoid micro UAV, the large Volcano, and the workhorse Bat. MLB 
is a small company with their business office loeated in Mountain View, CA. They were 
contracted to support the March testing with their Volcano UAV. The Volcano aircraft is 
designed to earry a 15 lb payload and up to an altitude of 12000 ft.ii6 

During the March testing, the Volcano was utilized as a communieations relay. A 
small wooden platform was strapped to the bottom of the plane with an omni-directional 
antenna, aeeess point, DC to AC power converter, and one lithium battery used as the 
power source. The aireraft flew for about 3 hours a day for a three-day period. It was 
flying at altitudes from 400 to 1,000 feet. There was an onboard camera that could be 

116 http://www.spvplanes.com/companv.html (April 2004). 
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viewed from the base station where the aireraft was being controlled. Thus, the Volcano 
could double in its mission by doing aerial reconnaissance and communications relay 
simultaneously. 

The aircraft was launched from the airfield runway, which it required about 500 
feet of, with a handheld remote-control device. Once it was airborne, the computer 
program designed for the Volcano automatically controlled the UAV in accordance with 
the inputted track data. This program was able to save the track information from the 
entire flight, so one could tell where the aircraft had flown during its mission. 

Communications on the ground to the UAV were very challenging mostly due to 
the antenna setup. Omni-directional antennas of 5 dBi gain with 1-Watt amplifiers were 
used on the ground and in the air. It was believed that the reason communication proved 
so difficult was the antenna on the UAV was pointing down from the bottom of the 
aircraft. Thus, its radiation pattern was mostly blocked. Ideally, the antenna should have 
been mounted pointing up in an open area on the aircraft. Another solution is to put 
better gain antennas and/or higher-powered amplifiers both on the ground and in the air. 

For information on MLB Company and their UAVs, contact Stephen Morris at 
650-966-1022 (office) or 650-757-5613 (cell). His e-mail address is 
smorris@spvplanes.com . 


Y. TETHERED BALLOON 

The tethered balloon is approximately 12 feet in diameter when filled completely 
with helium. Several tanks of helium are needed for operation of the balloon. It takes 
roughly an hour to fill the balloon completely with helium. Since the balloon was used 
on multiple days, it was kept filled overnight and tied down. This alleviated the need to 
constantly refill it. If there are winds over 15 mph, the balloon should be deflated 
overnight to eliminate any possible damage. While airborne, the balloon does not 
perform well in high winds either. Any wind over 20 mph, the balloon should not be 
flown to alleviate any possible damage. In addition, due to the constant movement of the 
balloon in high winds, any connectivity trying to be established is very unreliable. 
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The balloon can carry a payload of up to 50 pounds. As seen in Figure 4, the 
payload is located underneath the balloon. For the March testing, the payload contained 
an omni-directional antenna, access point, 1-Watt Amplifier, DC to AC power 
converters, and two Lithium batteries used as the power source. A research associate at 
NFS, Kevin Jones, built this payload. 

To let out or bring in the balloon, an attached motor controlled a large reel of 
string. The balloon could reach an altitude of approximately 3,000 feet. To fly the 
balloon, a large open area was needed because high winds could cause the balloon to be 
pushed horizontal rather than vertical. Figure 81 displays the balloon while airborne. 





Figure 82. TETHERED BAEEOON WITH PAYEOAD UNDERNEATH 

Z, FIELD TEST TEMPLATE 

The following information is a template that was used in the writing of the field 

tests. 

TEST PLAN and REPORT EORMATS 


GENERAL; Ideally, an experiment is reported on in two documents, an 
experimental plan that lays the foundation, and an experimental report that tells what 
actually took place and what the results were. For this thesis work the authors did not 
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produce elaborate experimental plans, so they moved some of the information into the 
report. The following outline is suggested. Parenthetieal notes identify further 
explanation of information that is eontained in the seetion. 

1. Introduction 

A. Introduee the team (who) 

B. Purpose 

C. The real world problem the experiment will help solve (what) 

D. The speeifie questions the experiment seeks to answer 

E. The Methodology (approaeh - how) 

F. Anticipated Results 

G. Seope of Experiment (why) 

2. Experimental Design 

A. Setup 

B. Physieal (loeation and time frame of experiment -when, and where) 

C. Test subjeets (technologies tested) 

D. Sehedule of Trials (planned sehedule) 

E. Assumptions 

F. Statistical Design of Experiment (network diagram) 

G. Instrumentation (equipment used for eolleeting data) 

H. Testing & Pilot Trials (baseline results) 

3. Data Description 

A. Example of raw data 

B. Data problems 

C. Data table 
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4, Analysis (both; findings and analysis) 

A. Findings 

B. Analysis (summary of experiment) 

5, Conclusions 

A. Experiment Summary 

B. Real world results of experiment 

6, Recommendations 

A. Changes to the Experiment 

B. Continuation of the Experiment 
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LIST OF ACRONYMS AND ABBREVIATIONS 


ACE 

Aviation Combat Element 

ATC 

Air Traffic Control 

ATM 

Asynchronous Transfer Mode 

BIOS 

Beyond Line of Sight 

CAC2S 

Common Aviation Comand and Control System 

CE 

Command Element 

COC 

Combat Operations Center 

CoNDOR 

Command and Control On the Move Network, Digital Over the Horizon Relay 

CS 

Communications Subsystem 

CSSE 

Combat Service Support Element 

DASC 

Direct Air Support Center 

DOD 

Department of Defense 

DSU 

Digital Switch Unit 

EIGRP 

Enhanced Interior Gateway Routing Protocol 

EPLRS 

Enhanced Position Locating and Reporting System 

FSO 

Free Space Optics 

GCE 

Ground Combat Element 

GDDS 

General Dynamics Decision Systems 

GET 

Generator, Environmental Control Unit, and Tent 

GUI 

Graphical User Interface 

HP 

High Frequency 

HMMWV 

High Mobility Multi-Purpose Wheeled Vehicle 

IEEE 

Institute of Electrical and Electronics Engineers 

IMUX 

Iridium Inverse Multiplexer 

INE 

In-Line Network Encryptor 

IP 

Internet Protocol 

JTRS 

Joint Tactical Radio System 

LAAD 

Low Altitude Air Defense 

LAN 

Local Area Network 

LOS 

Line of Sight 

MAC 

Media Access Control 

MACCS 

Marine Aviation Command and Control System 

MAGTF 

Marine Aviation-Ground Task Force 

MAR 

Mobile Access Router 

MCSC 

Marine Corps Systems Command 

MCTSSA 

Marine Corps Tactical Systems Support Activity 

MEF 

Marine Expeditionary Force 

MRC 

Mobile Radio Component 

MRF 

Mobile Research Facility 

MSC 

Major Subordinate Command 

NLOS 

Non Line of Sight 

NOC 

Network Operations Center 

NPS 

Naval Postgraduate School 

ODU 

Outdoor Mounted Unit 
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OFDM 

Orthogonal Frequency Division Multiplexing 

OIF 

Operation Iraqi Freedom 

OTH 

Over The Horizon 

PDS 

Processing and Disply Subsystem 

POP 

Point of Presence 

PRC 

Portable Radio Component 

RF 

Radio Frequency 

RFM 

Radio Frequency Module 

SCOP 

Skinny Client Control Protocol 

SDS 

Sensor Data Subsystem 

SIP 

Session Initiated Protocol 

SMART-T 

Secure, Mobile, Anit-Jam, Reliable Tactical Terminal 

SSID 

Service Set Identifier 

TACO 

Tactical Air Command Center 

TAOC 

Tactical Air Operations Center 

TCP 

Transport Control Protocol 

TDN 

Tactical Data Network 

TRC 

Tactical Radio Component 

UAV 

Unmanned Aerial Vehicle 

UHF 

Ultra High Frequency 

UOC 

Unit Operations Center 

USMC 

United States Marine Corps 

USN 

United States Navy 

VHF 

Very High Frequency 

VoIP 

Voice over Internet Protocol 

WAN 

Wide Area Network 

WAP 

Wireless Access Point 
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